Hi all,
I have set up trust between FreeIPA and AD. Users from AD domain can successfully log into the linux boxes when I have allow_all rule enabled. However, when I try to achieve something more fancy, like assigning set of users to a custom group (firstly external, then the posix one) or make it possible for AD users to use ssh public key authentication via Default Trust View user settings override, FreeIPA behaves in slightly nondeterministic way. It manifests itself in a couple of ways: - users that I uploaded SSH keys for can't use them right away. Sometimes it is a matter of minutes, sometimes it is a matter of hours for the ssh public keys to work. I observed that when I add a couple of keys, then whenever one ssh public key starts working for one user, it works for all of them. - the same as above applies to AD users that are added to a group which later on is used in HBAC rule definition. When I add a user to this group, he/she can't log in straight away but it takes some time to propagate. - and last but not least: when I delete a user who can successfully log into a Linux box from a group which is used in HBAC rule definition, he/she can still log in to that box. To make things more awkward, user can access one client machine as if they wasn't deleted from the group whereas they can't access other client machine and receives "Connection closed by UNKNOWN" response upon ssh connection establishment (which is desired in both Linux machines).
I tried to clear sssd cache by issuing sss_cache -E and restarted sssd daemon on Linux machine which is affected by that behaviour, but to no avail.
Can someone please point me to what I can do to troubleshoot this further and make changes applied to IPA server be visible right away?
Many thanks, Bart
Bart,
Which versions of SSSD and FreeIPA are you using?
cheers L.
------ "Mission Statement: To provide hope and inspiration for collective action, to build collective power, to achieve collective transformation, rooted in grief and rage but pointed towards vision and dreams."
- Patrisse Cullors, *Black Lives Matter founder*
On 6 July 2017 at 00:22, bogusmaster--- via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hi all,
I have set up trust between FreeIPA and AD. Users from AD domain can successfully log into the linux boxes when I have allow_all rule enabled. However, when I try to achieve something more fancy, like assigning set of users to a custom group (firstly external, then the posix one) or make it possible for AD users to use ssh public key authentication via Default Trust View user settings override, FreeIPA behaves in slightly nondeterministic way. It manifests itself in a couple of ways:
- users that I uploaded SSH keys for can't use them right away. Sometimes
it is a matter of minutes, sometimes it is a matter of hours for the ssh public keys to work. I observed that when I add a couple of keys, then whenever one ssh public key starts working for one user, it works for all of them.
- the same as above applies to AD users that are added to a group which
later on is used in HBAC rule definition. When I add a user to this group, he/she can't log in straight away but it takes some time to propagate.
- and last but not least: when I delete a user who can successfully log
into a Linux box from a group which is used in HBAC rule definition, he/she can still log in to that box. To make things more awkward, user can access one client machine as if they wasn't deleted from the group whereas they can't access other client machine and receives "Connection closed by UNKNOWN" response upon ssh connection establishment (which is desired in both Linux machines).
I tried to clear sssd cache by issuing sss_cache -E and restarted sssd daemon on Linux machine which is affected by that behaviour, but to no avail.
Can someone please point me to what I can do to troubleshoot this further and make changes applied to IPA server be visible right away?
Many thanks, Bart _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Bart,
Which versions of SSSD and FreeIPA are you using?
cheers L.
------ "Mission Statement: To provide hope and inspiration for collective action, to build collective power, to achieve collective transformation, rooted in grief and rage but pointed towards vision and dreams."
- Patrisse Cullors, *Black Lives Matter founder*
On 6 July 2017 at 00:22, bogusmaster--- via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hi all,
I have set up trust between FreeIPA and AD. Users from AD domain can successfully log into the linux boxes when I have allow_all rule enabled. However, when I try to achieve something more fancy, like assigning set of users to a custom group (firstly external, then the posix one) or make it possible for AD users to use ssh public key authentication via Default Trust View user settings override, FreeIPA behaves in slightly nondeterministic way. It manifests itself in a couple of ways:
- users that I uploaded SSH keys for can't use them right away. Sometimes
it is a matter of minutes, sometimes it is a matter of hours for the ssh public keys to work. I observed that when I add a couple of keys, then whenever one ssh public key starts working for one user, it works for all of them.
- the same as above applies to AD users that are added to a group which
later on is used in HBAC rule definition. When I add a user to this group, he/she can't log in straight away but it takes some time to propagate.
- and last but not least: when I delete a user who can successfully log
into a Linux box from a group which is used in HBAC rule definition, he/she can still log in to that box. To make things more awkward, user can access one client machine as if they wasn't deleted from the group whereas they can't access other client machine and receives "Connection closed by UNKNOWN" response upon ssh connection establishment (which is desired in both Linux machines).
I tried to clear sssd cache by issuing sss_cache -E and restarted sssd daemon on Linux machine which is affected by that behaviour, but to no avail.
Can someone please point me to what I can do to troubleshoot this further and make changes applied to IPA server be visible right away?
Many thanks, Bart _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Hi Lachlan,
I am using these versions:
ipa-client.x86_64 4.4.0-14.el7.centos.7 installed sssd.x86_64 1.14.0-43.el7_3.18 installed
Bart
Can I recommend you test using the SSSD 1.15 from the COPR repo?
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-15/
I had a similar problem, and this worked for me.
cheers L.
------ "Mission Statement: To provide hope and inspiration for collective action, to build collective power, to achieve collective transformation, rooted in grief and rage but pointed towards vision and dreams."
- Patrisse Cullors, *Black Lives Matter founder*
On 6 July 2017 at 18:36, bogusmaster--- via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Hi Lachlan,
I am using these versions:
ipa-client.x86_64 4.4.0-14.el7.centos.7 installed sssd.x86_64 1.14.0-43.el7_3.18 installed
Bart _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Just to add some example of behaviour I described, I configured an AD user group membership and granted him access via HBAC rule. Waited approximately for 2 hours and then, all of a sudden, it magically works without me changing anything :). Below is the log excerpt from /var/log/secure which caught the moment when HBAC rule seemingly started working with no action on my side:
Jul 6 14:15:19 idm-client sshd[4069]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:15:21 idm-client sshd[4073]: pam_sss(sshd:account): Access denied for user jdoe@my.test.domain.com: 6 (Permission denied) Jul 6 14:15:21 idm-client sshd[4073]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:15:25 idm-client sshd[4077]: pam_sss(sshd:account): Access denied for user jdoe@my.test.domain.com: 6 (Permission denied) Jul 6 14:15:25 idm-client sshd[4077]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:15:47 idm-client sshd[4082]: pam_sss(sshd:account): Access denied for user jdoe@my.test.domain.com: 6 (Permission denied) Jul 6 14:15:47 idm-client sshd[4082]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:16:11 idm-client polkitd[9042]: Registered Authentication Agent for unix-process:4087:70613648 (system bus name :1.652 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Jul 6 14:16:11 idm-client polkitd[9042]: Unregistered Authentication Agent for unix-process:4087:70613648 (system bus name :1.652, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) Jul 6 14:17:51 idm-client sshd[4104]: Accepted publickey for jdoe@my.test.domain.com from XXX.XXX.XXX.XXX port 58220 ssh2: RSA 63:32:b6:62:99:6c:4c:13:c6:ef:8b:16:6d:05:54:8e Jul 6 14:17:51 idm-client sshd[4104]: pam_unix(sshd:session): session opened for user jdoe@my.test.domain.com by (uid=0) Jul 6 14:17:54 idm-client sshd[4109]: Received disconnect from XXX.XXX.XXX.XXX: 11: disconnected by user Jul 6 14:17:54 idm-client sshd[4104]: pam_unix(sshd:session): session closed for user jdoe@my.test.domain.com
On Thu, Jul 06, 2017 at 02:29:34PM -0000, bogusmaster--- via FreeIPA-users wrote:
Just to add some example of behaviour I described, I configured an AD user group membership and granted him access via HBAC rule. Waited approximately for 2 hours and then, all of a sudden, it magically works without me changing anything :). Below is the log excerpt from /var/log/secure which caught the moment when HBAC rule seemingly started working with no action on my side:
The ipa-client gets all its data from the IPA server and for efficiency the lookup on the server goes via the SSSD cache on the server.
While on the client during authentication the user data is refreshed unconditionally the old data might still be on the cache on the server. I would expect that when you call 'sss_cache -E' on the IPA server after changing the group memberships the client should see the new groups during authentication and access should be granted.
HTH
bye, Sumit
Jul 6 14:15:19 idm-client sshd[4069]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:15:21 idm-client sshd[4073]: pam_sss(sshd:account): Access denied for user jdoe@my.test.domain.com: 6 (Permission denied) Jul 6 14:15:21 idm-client sshd[4073]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:15:25 idm-client sshd[4077]: pam_sss(sshd:account): Access denied for user jdoe@my.test.domain.com: 6 (Permission denied) Jul 6 14:15:25 idm-client sshd[4077]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:15:47 idm-client sshd[4082]: pam_sss(sshd:account): Access denied for user jdoe@my.test.domain.com: 6 (Permission denied) Jul 6 14:15:47 idm-client sshd[4082]: fatal: Access denied for user jdoe@my.test.domain.com by PAM account configuration [preauth] Jul 6 14:16:11 idm-client polkitd[9042]: Registered Authentication Agent for unix-process:4087:70613648 (system bus name :1.652 [/usr/bin/pkttyagent --notify-fd 5 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) Jul 6 14:16:11 idm-client polkitd[9042]: Unregistered Authentication Agent for unix-process:4087:70613648 (system bus name :1.652, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8) (disconnected from bus) Jul 6 14:17:51 idm-client sshd[4104]: Accepted publickey for jdoe@my.test.domain.com from XXX.XXX.XXX.XXX port 58220 ssh2: RSA 63:32:b6:62:99:6c:4c:13:c6:ef:8b:16:6d:05:54:8e Jul 6 14:17:51 idm-client sshd[4104]: pam_unix(sshd:session): session opened for user jdoe@my.test.domain.com by (uid=0) Jul 6 14:17:54 idm-client sshd[4109]: Received disconnect from XXX.XXX.XXX.XXX: 11: disconnected by user Jul 6 14:17:54 idm-client sshd[4104]: pam_unix(sshd:session): session closed for user jdoe@my.test.domain.com _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On Thu, Jul 06, 2017 at 02:29:34PM -0000, bogusmaster--- via FreeIPA-users wrote:
The ipa-client gets all its data from the IPA server and for efficiency the lookup on the server goes via the SSSD cache on the server.
While on the client during authentication the user data is refreshed unconditionally the old data might still be on the cache on the server. I would expect that when you call 'sss_cache -E' on the IPA server after changing the group memberships the client should see the new groups during authentication and access should be granted.
I cleared cache on the IPA server and restarted sssd after changing group membership, did the same on the client but it didn't help.
On Thu, Jul 06, 2017 at 02:29:34PM -0000, bogusmaster--- via FreeIPA-users wrote:
The ipa-client gets all its data from the IPA server and for efficiency the lookup on the server goes via the SSSD cache on the server.
While on the client during authentication the user data is refreshed unconditionally the old data might still be on the cache on the server. I would expect that when you call 'sss_cache -E' on the IPA server after changing the group memberships the client should see the new groups during authentication and access should be granted.
HTH
bye, Sumit
I have verified that hint. I've stopped sssd daemon, cleared the cache and started it back again. Although ipa commands are returning correct members of the group, when in issue getent group ... on the server it still returns old members of the group that are not present in the group returned by ipa command. Can you please advise on how I can troubleshoot it further? Best, Bart
On 13 July 2017 at 00:48, bogusmaster--- via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
On Thu, Jul 06, 2017 at 02:29:34PM -0000, bogusmaster--- via
FreeIPA-users wrote:
I have verified that hint. I've stopped sssd daemon, cleared the cache and started it back again. Although ipa commands are returning correct members of the group, when in issue getent group ... on the server it still returns old members of the group that are not present in the group returned by ipa command. Can you please advise on how I can troubleshoot it further?
There are two parts to IPA - ipa server which does the "server" part, and SSSD, which does the client part. On the IPA server itself, if you are using SSSD, you might need to also update SSSD to 1.15.2-5 and clear the cache?
ipa-client basically installs SSSD and configures it for the ipa server in question.
cheers L.
------ "Mission Statement: To provide hope and inspiration for collective action, to build collective power, to achieve collective transformation, rooted in grief and rage but pointed towards vision and dreams."
- Patrisse Cullors, *Black Lives Matter founder*
On Wed, Jul 12, 2017 at 02:48:47PM -0000, bogusmaster--- via FreeIPA-users wrote:
On Thu, Jul 06, 2017 at 02:29:34PM -0000, bogusmaster--- via FreeIPA-users wrote:
The ipa-client gets all its data from the IPA server and for efficiency the lookup on the server goes via the SSSD cache on the server.
While on the client during authentication the user data is refreshed unconditionally the old data might still be on the cache on the server. I would expect that when you call 'sss_cache -E' on the IPA server after changing the group memberships the client should see the new groups during authentication and access should be granted.
HTH
bye, Sumit
I have verified that hint. I've stopped sssd daemon, cleared the cache and started it back again. Although ipa commands are returning correct members of the group, when in issue getent group ... on the server it still returns old members of the group that are not present in the group returned by ipa command. Can you please advise on how I can troubleshoot it further?
This sounds that SSSD cannot connect to the IPA server and returns old data from the cache.
Can you check if
sssctl domain-status your.ipa.domain
returns 'Offline' or check the sss_your.ipa.domain.log file for any messages related to connection failures and going offline? You might need to increase the debug_level for the latter.
bye, Sumit
Best, Bart _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Thank you for the answer.
I've verified the status of domain on both server and client. On a server it appears that IPA domain (ipa.sub.mydomain.com) is always online. However, status of AD domain (sub.mydomain.com) seems to be fluctuating between Online and Offline and sometimes sssctl returns communication error:
[root@idm4 ~]# sssctl domain-status sub.mydomain.com Unable to get online status [3]: Communication error org.freedesktop.sssd.Error.UnknownDomain: Unknown domain Unable to get online status [root@idm4 ~]# sssctl domain-status sub.mydomain.com Online status: Online
Active servers: AD Global Catalog: not connected AD Domain Controller: dc.sub.mydomain.com IPA: idm4.ipa.sub.mydomain.com
Discovered AD Global Catalog servers: None so far.
Discovered AD Domain Controller servers: - dc.sub.mydomain.com
Discovered IPA servers: - idm4.ipa.sub.mydomain.com
On a client sssctl always shows that IPA domain is Online, but after clearing the sssd cache with sss_cache -E and restarting sssd daemon getent passwd command for AD users doesn't yield any results. I've double firewalls and turned them off both in AD controller and on Linux boxes but it doesn't change a thing.
On Thu, Jul 13, 2017 at 12:17:42PM -0000, bogusmaster--- via FreeIPA-users wrote:
Thank you for the answer.
I've verified the status of domain on both server and client. On a server it appears that IPA domain (ipa.sub.mydomain.com) is always online. However, status of AD domain (sub.mydomain.com) seems to be fluctuating between Online and Offline and sometimes sssctl returns communication error:
[root@idm4 ~]# sssctl domain-status sub.mydomain.com Unable to get online status [3]: Communication error org.freedesktop.sssd.Error.UnknownDomain: Unknown domain Unable to get online status [root@idm4 ~]# sssctl domain-status sub.mydomain.com Online status: Online
Active servers: AD Global Catalog: not connected AD Domain Controller: dc.sub.mydomain.com IPA: idm4.ipa.sub.mydomain.com
Discovered AD Global Catalog servers: None so far.
Discovered AD Domain Controller servers:
- dc.sub.mydomain.com
Discovered IPA servers:
- idm4.ipa.sub.mydomain.com
On a client sssctl always shows that IPA domain is Online, but after clearing the sssd cache with sss_cache -E and restarting sssd daemon getent passwd command for AD users doesn't yield any results. I've double firewalls and turned them off both in AD controller and on Linux boxes but it doesn't change a thing.
Can you send me the sssd_nss.log and sssd_your.domain.log from the client with debug_level=10 which include the getent passwd request?
bye, Sumit
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
I've uploaded them here: goo.gl/hiFHKE
Thank you, Bart
On Thu, Jul 13, 2017 at 07:22:58PM -0000, bogusmaster--- via FreeIPA-users wrote:
I've uploaded them here: goo.gl/hiFHKE
Thanks.
[ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: No such object(32), (null).
This indicates that the user cannot be found on the server. There are two reasons for this. Either the user itself cannot be looked up at all or the group memberships cannot be resolved completely.
Can you do a test on the server by calling
id username@ad.domain
and collect sssd_nss.log and sssd_your.ipa.domain.log on the server as well?
In the id output all groups should have a GID and a name, if there are groups with only a GID this might have caused the issue on the client as well.
bye, Sumit
Thank you, Bart _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
Can you do a test on the server by calling
id username(a)ad.domainand collect sssd_nss.log and sssd_your.ipa.domain.log on the server as well?
I uploaded these files to the same place as before - goo.gl/hiFHKE. They have SERVER prefix in their names.
In the id output all groups should have a GID and a name, if there are groups with only a GID this might have caused the issue on the client as well.
This could be root cause of the issues with rules propagation, because: groups jdoe@td.mydomain.com jdoe@td.mydomain.com : jdoe@td.mydomain.com groups: cannot find name for group ID 752600513 752600513
Interestingly, ipa group-find doesn't show a group with that id, nor do I recognize adding a group with such ID. I tried to resolve it by adding a group with such ID locally on the server, but it didn't change anything except for the result of groups command above.
I also observed one peculiar thing when it comes to group membership of the group which is used in my HBAC rule. When I issue getent group ad_users on the server, I get: ad_users:*:1010200005:jdoe@td.mydomain.com
In the FreeIPA's web UI membership looks like follows:
External member S-1-5-21-4217214799-1184961203-849681438-1104 S-1-5-21-4217214799-1184961203-849681438-1111 jdoe@td.mydomain.com
and ipa group-find returns these members: Group name: ad_users_external Description: ad_domain users external map External member: S-1-5-21-4217214799-1184961203-849681438-1121, S-1-5-21-4217214799-1184961203-849681438-1104, S-1-5-21-4217214799-1184961203-849681438-1111
Could it also be that due to what is displayed in the FreeIPA's UI other two members are not returned correctly by the getent command?
On Fri, Jul 14, 2017 at 10:00:20AM -0000, bogusmaster--- via FreeIPA-users wrote:
Can you do a test on the server by calling
id username(a)ad.domainand collect sssd_nss.log and sssd_your.ipa.domain.log on the server as well?
I uploaded these files to the same place as before - goo.gl/hiFHKE. They have SERVER prefix in their names.
In the id output all groups should have a GID and a name, if there are groups with only a GID this might have caused the issue on the client as well.
This could be root cause of the issues with rules propagation, because: groups jdoe@td.mydomain.com jdoe@td.mydomain.com : jdoe@td.mydomain.com groups: cannot find name for group ID 752600513 752600513
yes, but I think this is only a side effect. SSSD cannot resolve a global catalog server. Does
dig SRV _gc._tcp.td.mydomain.com
return anything when called on the IPA server?
Interestingly, ipa group-find doesn't show a group with that id, nor do I recognize adding a group with such ID.
It is most probably the GID of the 'Domain Users' group of the AD domain.
I tried to resolve it by adding a group with such ID locally on the server, but it didn't change anything except for the result of groups command above.
Please remove the entry again, it might cause all kind of irritations.
bye, Sumit
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On Fri, Jul 14, 2017 at 10:00:20AM -0000, bogusmaster--- via FreeIPA-users wrote:
yes, but I think this is only a side effect. SSSD cannot resolve a global catalog server. Does
dig SRV _gc._tcp.td.mydomain.comreturn anything when called on the IPA server?
It didn't. I've added a DNS entry and now it works like this: dig +short SRV _gc._tcp.td.mydomain.com 0 100 389 dc.td.mydomain.com.
Now when I clear server's cache by removing the files in /var/lib/sss/db/ and restart sssd daemon it apparently behaves as it should - ad_users group that I use for HBAC for AD users gets updated. sss_cache -E doesn't work for me and I have to delete cache files manually. I will test group membership propagation a little bit more to be 100% sure, though.
Is there any other way for these changes to propagate without a restart? I have this entry in sssd.conf: entry_cache_timeout = 60 but it doesn't seem to work.
Best, Bart
It is most probably the GID of the 'Domain Users' group of the AD domain.
Please remove the entry again, it might cause all kind of irritations.
I've removed that, it was just for the testing purpose.
On Fri, Jul 14, 2017 at 03:19:57PM -0000, bogusmaster--- via FreeIPA-users wrote:
On Fri, Jul 14, 2017 at 10:00:20AM -0000, bogusmaster--- via FreeIPA-users wrote:
yes, but I think this is only a side effect. SSSD cannot resolve a global catalog server. Does
dig SRV _gc._tcp.td.mydomain.comreturn anything when called on the IPA server?
It didn't. I've added a DNS entry and now it works like this: dig +short SRV _gc._tcp.td.mydomain.com 0 100 389 dc.td.mydomain.com.
What DNS server are you using? Typically the AD DNS servers will have set this automatically.
Now when I clear server's cache by removing the files in /var/lib/sss/db/ and restart sssd daemon it apparently behaves as it should - ad_users group that I use for HBAC for AD users gets updated. sss_cache -E doesn't work for me and I have to delete cache files manually. I will test group membership propagation a little bit more to be 100% sure, though.
Is there any other way for these changes to propagate without a restart? I have this entry in sssd.conf: entry_cache_timeout = 60 but it doesn't seem to work.
This might be a side effect of the timestamp cache. If there is no change in the related object on the server-side the update might be skipped.
Does it work if you remove only the timestamp cache from /var/lib/sss/db/ ?
bye, Sumit
Best, Bart
It is most probably the GID of the 'Domain Users' group of the AD domain.
Please remove the entry again, it might cause all kind of irritations.
I've removed that, it was just for the testing purpose. _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On 7 July 2017 at 00:29, bogusmaster--- via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Just to add some example of behaviour I described, I configured an AD user group membership and granted him access via HBAC rule. Waited approximately for 2 hours and then, all of a sudden, it magically works without me changing anything :). Below is the log excerpt from /var/log/secure which caught the moment when HBAC rule seemingly started working with no action on my side:
You are describing the symptoms I saw exactly. The newer SSSD version (1.15.2-5) from the COPR repo (which is managed by some of the sssd developers) solved my problems.
cheers L.
Thank you for sharing this hint, I am going to try the upgrade. Can I ask you which version of IPA did you use with that sssd version? Did you upgrade sssd on each type of server (I mean both client and server)?
Many thanks, Bart
Thank you for sharing this hint, I am going to try the upgrade. Can I ask you which version of IPA did you use with that sssd version? Did you upgrade sssd on each type of server (I mean both client and server)?
I did a test roll out to just the clients before going to all. We are using the freeIPA that is currently in CentOS/EPEL - 4.4 I think?
Cheers L.
------ "Mission Statement: To provide hope and inspiration for collective action, to build collective power, to achieve collective transformation, rooted in grief and rage but pointed towards vision and dreams."
- Patrisse Cullors, *Black Lives Matter founder*
On 7 July 2017 at 22:54, bogusmaster--- via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Many thanks, Bart _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
This is the exact configuration that I am currently using (sssd 1.15 from COPR repo and freeIPA 4.4) and I'm still having issues with group membership.
What was the IPA version you used? It might be not related, but when i upgraded sssd to 1.15.2-5 ssh doesn't work for me neither on the FreeIPA server, nor on the clients. What's more strange, getent passwd for AD users doesn't work for the clients, although it works for the server.
freeipa-users@lists.fedorahosted.org
-
bogusmaster＠o2.pl -
Lachlan Musicman -
Sumit Bose