[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away
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:*:101025:j...@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- j...@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- 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? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away
> 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. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away
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 mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away
> 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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away
> 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. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away
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. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: HBAC rules / ssh keys for AD users not working right away
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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Kvno error on validating one-way trust: "kvno: Decrypt integrity check failed while getting credentials"
Hi All, I am setting up a one-way trust from FreeIPA server to AD domain with a pre-shared key. It seems that it was set up successfully but I cannot verify the Kerberos configuration when I follow the steps described here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/trust-during.html#create-a-trust. Although I successfuly kinit with a username from AD domain and obtain a ticket: klist Ticket cache: KEYRING:persistent:0:0 Default principal: testu...@domain.com Valid starting Expires Service principal 08/22/2017 09:47:41 08/22/2017 19:47:41 krbtgt/domain@domain.com renew until 08/23/2017 09:47:34 I am not able to request service tickets for a service within IdM domain: [root@idm1 ~]# KRB5_TRACE=/dev/stdout kvno -S host idm1.ipa.domain.com [16119] 1503409696.153004: Getting credentials testu...@domain.com -> host/idm1.ipa.domain@ipa.domain.com using ccache KEYRING:persistent:0:0 [16119] 1503409696.153288: Retrieving testu...@domain.com -> host/idm1.ipa.domain@ipa.domain.com from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16119] 1503409696.153422: Retrieving testu...@domain.com -> krbtgt/ipa.domain@ipa.domain.com from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16119] 1503409696.153520: Retrieving testu...@domain.com -> krbtgt/domain@domain.com from KEYRING:persistent:0:0 with result: 0/Success [16119] 1503409696.153536: Starting with TGT for client realm: testu...@domain.com -> krbtgt/domain@domain.com [16119] 1503409696.153600: Retrieving testu...@domain.com -> krbtgt/ipa.domain@ipa.domain.com from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16119] 1503409696.153609: Requesting TGT krbtgt/ipa.domain@domain.com using TGT krbtgt/domain@domain.com [16119] 1503409696.153663: Generated subkey for TGS request: aes256-cts/A13D [16119] 1503409696.153718: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4 [16119] 1503409696.153875: Encoding request body and padata into FAST request [16119] 1503409696.153942: Sending request (1851 bytes) to DOMAIN.COM [16119] 1503409696.154236: Resolving hostname domain.com [16119] 1503409696.290796: Initiating TCP connection to stream 10.10.10.10:88 [16119] 1503409696.398086: Sending TCP request to stream 10.10.10.10:88 [16119] 1503409696.836098: Received answer (1551 bytes) from stream 10.10.10.10:88 [16119] 1503409696.836121: Terminating TCP connection to stream 10.10.10.10:88 [16119] 1503409696.836212: Response was from master KDC [16119] 1503409696.836258: Decoding FAST response [16119] 1503409696.836423: TGS reply is for testu...@domain.com -> krbtgt/ipa.domain@domain.com with session key aes256-cts/C0B1 [16119] 1503409696.836454: TGS request result: 0/Success [16119] 1503409696.836461: Received TGT for offpath realm ipa.domain.com [16119] 1503409696.836468: Requesting TGT krbtgt/ipa.domain@ipa.domain.com using TGT krbtgt/ipa.domain@domain.com [16119] 1503409696.836486: Generated subkey for TGS request: aes256-cts/743D [16119] 1503409696.836523: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4 [16119] 1503409696.836579: Encoding request body and padata into FAST request [16119] 1503409696.836648: Sending request (1854 bytes) to ipa.domain.com [16119] 1503409696.904352: Resolving hostname idm1.ipa.domain.com. [16119] 1503409696.938147: Sending initial UDP request to dgram 10.10.10.11:88 [16119] 1503409696.943465: Received answer (146 bytes) from dgram 10.10.10.11:88 [16119] 1503409696.977047: Response was from master KDC [16119] 1503409696.977102: TGS request result: -1765328353/Decrypt integrity check failed kvno: Decrypt integrity check failed while getting credentials for host/idm1.ipa.domain@ipa.domain.com Can you please advise me on how to resolve this issue? Bart ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Kvno error on validating one-way trust: "kvno: Decrypt integrity check failed while getting credentials"
Behavior that I described above pertains to Windows 2008 R2. When I attempt at doing exactly the same with AD set up on top of Windows 2012, it works flawlessly. Unfortunately, environment I have to set up trust with uses Windows 2008 R2. I am wondering what might be the difference between these two versions that prevent trust from working in case of Windows 2008 R2. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
