I just added my first ubuntu 16.04 client to our IPA domain and am having problem with HBAC rules randomly denying access to a user that should have access. Users are in AD (ad.nwra.com), I have an external group containing the AD user linked to an IPA group used for the HBAC rule. Much of the time it will work, but sometimes not.
sssd.conf: [domain/nwra.com] cache_credentials = True krb5_auth_timeout = 30 krb5_store_password_if_offline = True ipa_domain = nwra.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_server = ipa.nwra.com, _srv_ ldap_tls_cacert = /etc/ipa/ca.crt dns_discovery_domain = nwra.com timeout = 20 debug_level = 5
[sssd] services = nss, sudo, pam, ssh, autofs domains = nwra.com default_domain_suffix = ad.nwra.com debug_level = 5
This is with 1.13.4-1ubuntu1.8
Is there any hope for this version to work? Any reliable source for an updated package?
On 7 October 2017 at 09:37, Orion Poplawski orion@nwra.com wrote:
I just added my first ubuntu 16.04 client to our IPA domain and am having problem with HBAC rules randomly denying access to a user that should have access. Users are in AD (ad.nwra.com), I have an external group containing the AD user linked to an IPA group used for the HBAC rule. Much of the time it will work, but sometimes not.
sssd.conf: [domain/nwra.com] cache_credentials = True krb5_auth_timeout = 30 krb5_store_password_if_offline = True ipa_domain = nwra.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_server = ipa.nwra.com, _srv_ ldap_tls_cacert = /etc/ipa/ca.crt dns_discovery_domain = nwra.com timeout = 20 debug_level = 5
[sssd] services = nss, sudo, pam, ssh, autofs domains = nwra.com default_domain_suffix = ad.nwra.com debug_level = 5
This is with 1.13.4-1ubuntu1.8
Is there any hope for this version to work? Any reliable source for an updated package?
You should check your sssd_domain logs (sssd_ad.nwra.com.log) for a time when someone is being denied - search for hbac_eval_user_element and check the number it returns versus the number of AD groups that user belongs to.
If the problem is that sssd isn't getting the right number of groups, then updating to sssd version 1.15.3 will work.
I don't know if or where that's packaged for ubuntu, sorry.
I know it can be hard to reproduce, but if you can reproduce it, on the client do:
- run the date command - run the login unsuccessfully (if it is indeed hbac for login) - run the date command.
Then check the IPA logs for entries between the dates.
Cheers L.
------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. "
*Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857
On 10/06/2017 08:29 PM, Lachlan Musicman wrote:
You should check your sssd_domain logs (sssd_ad.nwra.com.log) for a time when someone is being denied - search for hbac_eval_user_element and check the number it returns versus the number of AD groups that user belongs to.
I've increased the logging to show this message now. We'll see if it happens again.
If the problem is that sssd isn't getting the right number of groups, then updating to sssd version 1.15.3 will work.
I don't know if or where that's packaged for ubuntu, sorry.
I know it can be hard to reproduce, but if you can reproduce it, on the client do:
- run the date command
- run the login unsuccessfully (if it is indeed hbac for login)
- run the date command.
Then check the IPA logs for entries between the dates.
Just to be clear, what IPA logs do you mean? I'm assuming you're talking about on the server? Or just the normal sssd logs on the client?
On 12 October 2017 at 08:35, Orion Poplawski orion@nwra.com wrote:
On 10/06/2017 08:29 PM, Lachlan Musicman wrote:
You should check your sssd_domain logs (sssd_ad.nwra.com.log) for a time
when
someone is being denied - search for hbac_eval_user_element and check the number it returns versus the number of AD groups that user belongs to.
I've increased the logging to show this message now. We'll see if it happens again.
If the problem is that sssd isn't getting the right number of groups,
then
updating to sssd version 1.15.3 will work.
I don't know if or where that's packaged for ubuntu, sorry.
I know it can be hard to reproduce, but if you can reproduce it, on the
client do:
- run the date command
- run the login unsuccessfully (if it is indeed hbac for login)
- run the date command.
Then check the IPA logs for entries between the dates.
Just to be clear, what IPA logs do you mean? I'm assuming you're talking about on the server? Or just the normal sssd logs on the client?
Yes, the logs on the server, not the client. Set the debug to 7, and then look in the log file titled (in Centos) sssd_unix.domain.org.log
Cheers L.
------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. "
*Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857
On 12 October 2017 at 08:44, Lachlan Musicman datakid@gmail.com wrote:
On 12 October 2017 at 08:35, Orion Poplawski orion@nwra.com wrote:
On 10/06/2017 08:29 PM, Lachlan Musicman wrote:
You should check your sssd_domain logs (sssd_ad.nwra.com.log) for a
time when
someone is being denied - search for hbac_eval_user_element and check
the
number it returns versus the number of AD groups that user belongs to.
I've increased the logging to show this message now. We'll see if it happens again.
If the problem is that sssd isn't getting the right number of groups,
then
updating to sssd version 1.15.3 will work.
I don't know if or where that's packaged for ubuntu, sorry.
I know it can be hard to reproduce, but if you can reproduce it, on the
client do:
- run the date command
- run the login unsuccessfully (if it is indeed hbac for login)
- run the date command.
Then check the IPA logs for entries between the dates.
Just to be clear, what IPA logs do you mean? I'm assuming you're talking about on the server? Or just the normal sssd logs on the client?
Be mindful though - Jacob is an sssd/ipa developer. I am someone that had a problem and Jacob's (and Sumit's and LS and...) advice got us home. Try his solution first.
L.
------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. "
*Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857
Does access work from any RHEL/CentOS client? (I’m asking because as long as those are fully patched, all HBAC-related bugs should be fixed there)
There was a bug that we fixed in commit 88f6d8ad4eef4b4fa032fd451ad732cf8201b0bf in the sssd-1-13 branch that should help.
However, that commit was not released as we didn’t release a 1.13.5 tarball yet (we should, but there are some pending regressions, see the pagure milestone for details).
I think in the meantime the best way is to file an Ubuntu bug and ask the maintainer to apply 88f6d8ad4eef4b4fa032fd451ad732cf8201b0bf
There should be no backporting necessary, the patch should apply cleanly.
On 7 Oct 2017, at 00:37, Orion Poplawski orion@nwra.com wrote:
I just added my first ubuntu 16.04 client to our IPA domain and am having problem with HBAC rules randomly denying access to a user that should have access. Users are in AD (ad.nwra.com), I have an external group containing the AD user linked to an IPA group used for the HBAC rule. Much of the time it will work, but sometimes not.
sssd.conf: [domain/nwra.com] cache_credentials = True krb5_auth_timeout = 30 krb5_store_password_if_offline = True ipa_domain = nwra.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_server = ipa.nwra.com, _srv_ ldap_tls_cacert = /etc/ipa/ca.crt dns_discovery_domain = nwra.com timeout = 20 debug_level = 5
[sssd] services = nss, sudo, pam, ssh, autofs domains = nwra.com default_domain_suffix = ad.nwra.com debug_level = 5
This is with 1.13.4-1ubuntu1.8
Is there any hope for this version to work? Any reliable source for an updated package?
-- Orion Poplawski Technical Manager of NWRA Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 https://www.nwra.com/ _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On 10/07/2017 10:17 AM, Jakub Hrozek wrote:
Does access work from any RHEL/CentOS client? (I’m asking because as long as those are fully patched, all HBAC-related bugs should be fixed there)
Yeah, all of our EL6/7 machines are working fine. This is the first Ubuntu machine I've had to deal with.
There was a bug that we fixed in commit 88f6d8ad4eef4b4fa032fd451ad732cf8201b0bf in the sssd-1-13 branch that should help.
However, that commit was not released as we didn’t release a 1.13.5 tarball yet (we should, but there are some pending regressions, see the pagure milestone for details).
I think in the meantime the best way is to file an Ubuntu bug and ask the maintainer to apply 88f6d8ad4eef4b4fa032fd451ad732cf8201b0bf
There should be no backporting necessary, the patch should apply cleanly.
Thanks for the info. I'll see what I can do.
On 7 Oct 2017, at 00:37, Orion Poplawski orion@nwra.com wrote:
I just added my first ubuntu 16.04 client to our IPA domain and am having problem with HBAC rules randomly denying access to a user that should have access. Users are in AD (ad.nwra.com), I have an external group containing the AD user linked to an IPA group used for the HBAC rule. Much of the time it will work, but sometimes not.
sssd.conf: [domain/nwra.com] cache_credentials = True krb5_auth_timeout = 30 krb5_store_password_if_offline = True ipa_domain = nwra.com id_provider = ipa auth_provider = ipa access_provider = ipa chpass_provider = ipa ipa_server = ipa.nwra.com, _srv_ ldap_tls_cacert = /etc/ipa/ca.crt dns_discovery_domain = nwra.com timeout = 20 debug_level = 5
[sssd] services = nss, sudo, pam, ssh, autofs domains = nwra.com default_domain_suffix = ad.nwra.com debug_level = 5
This is with 1.13.4-1ubuntu1.8
Is there any hope for this version to work? Any reliable source for an updated package?
-- Orion Poplawski Technical Manager of NWRA Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 https://www.nwra.com/ _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org