HBAC rules / ssh keys for AD users not working right away

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

[Lachlan Musicman]

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 <
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Lachlan Musicman]

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 <
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

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

[Lachlan Musicman]

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 <
[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

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 [e-mail] by PAM account configuration [preauth]
Jul  6 14:15:21 idm-client sshd[4073]: pam_sss(sshd:account): Access denied for user [e-mail]: 6 (Permission denied)
Jul  6 14:15:21 idm-client sshd[4073]: fatal: Access denied for user [e-mail] by PAM account configuration [preauth]
Jul  6 14:15:25 idm-client sshd[4077]: pam_sss(sshd:account): Access denied for user [e-mail]: 6 (Permission denied)
Jul  6 14:15:25 idm-client sshd[4077]: fatal: Access denied for user [e-mail] by PAM account configuration [preauth]
Jul  6 14:15:47 idm-client sshd[4082]: pam_sss(sshd:account): Access denied for user [e-mail]: 6 (Permission denied)
Jul  6 14:15:47 idm-client sshd[4082]: fatal: Access denied for user [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail]

[Sumit Bose]

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 [e-mail] by PAM account configuration [preauth]
> Jul  6 14:15:21 idm-client sshd[4073]: pam_sss(sshd:account): Access denied for user [e-mail]: 6 (Permission denied)
> Jul  6 14:15:21 idm-client sshd[4073]: fatal: Access denied for user [e-mail] by PAM account configuration [preauth]
> Jul  6 14:15:25 idm-client sshd[4077]: pam_sss(sshd:account): Access denied for user [e-mail]: 6 (Permission denied)
> Jul  6 14:15:25 idm-client sshd[4077]: fatal: Access denied for user [e-mail] by PAM account configuration [preauth]
> Jul  6 14:15:47 idm-client sshd[4082]: pam_sss(sshd:account): Access denied for user [e-mail]: 6 (Permission denied)
> Jul  6 14:15:47 idm-client sshd[4082]: fatal: Access denied for user [e-mail] 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 [e-mail] 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 [e-mail] 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 [e-mail]
> _______________________________________________
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

> 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

[Lachlan Musicman]

On 13 July 2017 at 00:48, bogusmaster--- via FreeIPA-users <
[e-mail]> 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*

[Sumit Bose]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

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.

[Sumit Bose]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

I've uploaded them here: goo.gl/hiFHKE

Thank you,
Bart

[Sumit Bose]

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 [e-mail]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

> Can you do a test on the server by calling
> id username(a)ad.domain
>
> and 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 [e-mail]
[e-mail] : [e-mail] 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:[e-mail]

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
    
[e-mail]

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?

[Sumit Bose]

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.domain
> >
> > and 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 [e-mail]
> [e-mail] : [e-mail] 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

> 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.com
>
> return 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.

[Sumit Bose]

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.com
> >
> > return 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Lachlan Musicman]

On 7 July 2017 at 00:29, bogusmaster--- via FreeIPA-users <
[e-mail]> 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

[Lachlan Musicman]

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 <
[e-mail]> wrote:
> Many thanks,
> Bart
> _______________________________________________
> FreeIPA-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

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.