Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID
On Tue, 17 Mar 2015, Guertin, David S. wrote: We have a trust relationship established between our AD domain and our IPA domain, and AD users can be found on the IPA server with id and getent passwd. When a user tries to SSH to the IPA server with AD credentials, the logs show: (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x0400): Processing user guertin-s (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x1000): Mapping user [guertin-s] objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to unix ID (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID It seems that this is a problem with the ID range, but I can't see where the problem is. We increased the default ranges of 200,000 to 2,000,000, which I would think should be able to handle a RID of 245906: # ipa idrange-find --all 2 ranges matched dn: cn=CSNS.MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu Range name: CSNS.MIDDLEBURY.EDU_id_range First Posix ID of the range: 182460 Number of IDs in the range: 200 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range iparangetyperaw: ipa-local objectclass: top, ipaIDrange, ipaDomainIDRange dn: cn=MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu Range name: MIDDLEBURY.EDU_id_range First Posix ID of the range: 1 Number of IDs in the range: 200 Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464 Range type: Active Directory trust range with POSIX attributes iparangetyperaw: ipa-ad-trust-posix objectclass: ipatrustedaddomainrange, ipaIDrange Number of entries returned 2 But the error remains. What am I missing? When you changed idrange, it helps to remove SSSD cache, both on IPA master and IPA clients and restart SSSD. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID
On Tue, 17 Mar 2015, Guertin, David S. wrote: When you changed idrange, it helps to remove SSSD cache, both on IPA master and IPA clients and restart SSSD. OK, I cleared the cache and restarted sssd with: sss_cache -E systemctl restart sssd Still no change in the error: Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID I don't think sss_cache -E removes cached idrange objects. You need to delete the databases in /var/lib/sss/db/. This is RHEL 7 running sssd-1.12.2 and ipa-server-4.1.0. You mean RHEL 7.1, right? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Only one AD user can able to login to IPA server
On Tue, 17 Mar 2015, Ben .T.George wrote: Hi i did kinit [root@kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab kinit: Keytab contains no suitable keys for host/kwtpocpbis01.solaris.local@SOLARIS.LOCAL while getting initial credentials i destroyed and re-created. but still same What did you destroy? Why did you need to touch /etc/dirsrv/ds.keytab at all? It contains key for ldap/kwtpocpbis01.solaris.local@SOLARIS.LOCAL that your LDAP server is using. It has nothing to do with your host/... principal. If your sssd cannot authenticate against AD DC, it means trust is *not* working and anything else is fruitless unless you fix it. hat do you see in /var/log/httpd/error_log as result of dumping netr_LogonControl2Ex structure? Can you follow http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust and tell what do you see in /var/log/httpd/error_log as result of dumping netr_LogonControl2Ex structure? We went through this few weeks ago and I'm not seeing what did you broke. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID
On Tue, 17 Mar 2015, Guertin, David S. wrote: When you changed idrange, it helps to remove SSSD cache, both on IPA master and IPA clients and restart SSSD. OK, I cleared the cache and restarted sssd with: sss_cache -E systemctl restart sssd Still no change in the error: Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID FWIW, here's my sssd.conf: [domain/csns.middlebury.edu] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = csns.middlebury.edu id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = genet.csns.middlebury.edu chpass_provider = ipa ipa_server = genet.csns.middlebury.edu ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [domain/middlebury.edu] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad debug_level = 10 Wait, why do you have middlebury.edu section here at all? If middlebury is trusted by csns.middlebury.edu, you should not have a separate [domain/middlebury.edu] section at all! The whole idea is that SSSD discovers all domains over trusted forest link path automatically. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] sssd options ignored?
On Tue, 17 Mar 2015, Gould, Joshua wrote: I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need to match whats in ipa idrange-find --all for the AD domain. # ipa idrange-mod --base-id=10 --range-size=90 --rid-base=0 Range name: TEST.OSUWMC_id_range Modified ID range "TEST.OSUWMC_id_range" Range name: TEST.OSUWMC_id_range First Posix ID of the range: 10 Number of IDs in the range: 90 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810 Range type: Active Directory domain range /etc/sssd/sssd.conf: [domain/test.osuwmc] ldap_idmap_range_min = 10 ldap_idmap_range_size = 90 There is something completely broken here. You *shouldn't* need to add a separate domain section for any of the domains coming over the forest trust link path _at_all_. SSSD automatically derives all needed parameters for them via its IPA providers for the primary IPA domain. Jakub, what is going on? From: , Joshua Gould Date: Tuesday, March 17, 2015 at 6:08 PM To: "freeipa-users@redhat.com" Subject: [Freeipa-users] sssd options ignored? I¹ve been getting messages like these when I try the id command for a test AD domain user: (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_get_primary_name] (0x0400): Processing object farus@test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0400): Processing user farus@test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x1000): Mapping user [farus@test.osuwmc] objectSID [S-1-5-21-226267946-722566613-1883572810-398410] to unix ID (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0020): Failed to save user [adm-faru03@test.osuwmc] Various sources all inicate that its a range issue with ldap_idmap_range_size. I¹ve tried several large values of just ldap_idmap_range_size as well as adding ldap_idmap_range_min and ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring the values? Between changing values I did stop sssd, delete the cache and restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58. Here is my full sssd.conf. [domain/unix.test.osuwmc] debug_level = 9 subdomains_provider = ipa cache_credentials = True krb5_store_password_if_offline = True ipa_domain = unix.test.osuwmc id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = mid-ipa-vp01.unix.test.osuwmc chpass_provider = ipa ipa_server = mid-ipa-vp01.unix.test.osuwmc ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt #ldap_idmap_range_min = 2000 #ldap_idmap_range_size = 90 #ldap_idmap_range_range = 3602000 ldap_idmap_range_size=100 ldap_id_mapping = True [sssd] services = nss, sudo, pam, ssh, pac config_file_version = 2 domains = unix.test.osuwmc [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] MIT Kerbetos & Samba 4
On Wed, 18 Mar 2015, Ondrej Valousek wrote: Hi list (Simo ;) Sorry for the bit off-topic question, but do we know whether Samba4 can now share the same KDC with IPA server so that it can act as AD DC? I heard MIT KDC functionality would have to be extended, but not sure whether this is on the roundmap or not. We are working on porting Samba AD DC to use MIT KDC. However, this usage is not meant for having the same KDC for both FreeIPA and Samba AD DC. Instead, they will have separate deployments connected to each other with the help of cross-forest trusts. Reports on the progress in this area will be given at SambaXP conference in May'15. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] sssd options ignored?
On Wed, 18 Mar 2015, Gould, Joshua wrote: On 3/18/15, 3:55 AM, "Sumit Bose" wrote: On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote: On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote: > On Tue, 17 Mar 2015, Gould, Joshua wrote: > >/etc/sssd/sssd.conf: > >[domain/test.osuwmc] > >ldap_idmap_range_min = 10 > >ldap_idmap_range_size = 90 > There is something completely broken here. Yes, the sssd.conf configuration :-) SSSD will not even read this sssd.conf section, it is just ignored. The subdomains are mostly auto-configured, just with several exceptions (like subdomain_homedir) where we read the subdomain config from the main domain config. > You *shouldn't* need to add a > separate domain section for any of the domains coming over the forest > trust link path _at_all_. SSSD automatically derives all needed > parameters for them via its IPA providers for the primary IPA domain. > > Jakub, what is going on? I would prefer if also Sumit can add his opinon since he authored the ID mapping code. as Alexander said in the other thread, only the IPA domain should be configured if you want to use IPA and trust. AD domains will be discovered and ranges will be configured on the IPA server side and IPA clients will get all information about trusted AD domains from the IPA server. So, please remove the section for the AD completely from sssd.conf. I¹ll be happy to remove the AD section from the sssd.conf file and test but I think there¹s more going on. The AD section was generated from the IPA client install. I never manually added anything other than ³pac² to the services line under the [sssd] section and the two ldap_idmap_range options. Show your /var/log/ipaclient-install.log. ipa-client-install has no support to generate sections for AD at all. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771",
B 3E 00 11 92 CB 92 8C 29 D5 90 31 B7 39 B1 31 .>.. )..1.9.1
[0130] 7C C3 0C C8 E5 D0 51 AA 20 D2 A2 39 C1 52 ED 91 |.Q. ..9.R..
[0140] 70 27 2F 7C EB 05 8F 91 AA EB 26 13 07 2C FA 62 p'/| ..&..,.b
[0150] C3 CB 79 DD B5 DA EC 3E 78 9A D8 A1 AE 64 3C 7F ..y> xd<.
[0160] BB CE 06 48 9A 56 6E 22 FC 6D 78 59 63 2F B8 51 ...H.Vn" .mxYc/.Q
[0170] D6 81 91 1D 54 94 2D C7 69 75 B3 E4 F1 77 93 EF T.-. iu...w..
[0180] BB 3E 0E 80 D7 D4 DD A0 DA 3C 10 51 64 5A AA A7 .>.. .<.QdZ..
[0190] CB AE CE DA BF F8 03 10 5C DB 64 9F 32 94 D4 F2 \.d.2...
[01A0] 67 1F D4 E7 4E 4F A3 DA A3 1A 24 FC 47 C9 73 FD g...NO.. ..$.G.s.
[01B0] AB 70 CB 34 BE 3B FF 12 A9 A3 DA 31 72 41 07 C0 .p.4.;.. ...1rA..
[01C0] 27 4A FF ED F8 C7 39 FD B6 87 2E 01 F9 0E 27 9F 'J9. ..'.
[01D0] 22 12 6B B3 A8 27 CB 86 A1 9D 8F D0 7A 70 97 66 ".k..'.. zp.f
[01E0] D4 AD 10 FF BF 88 3A 14 A4 D6 74 E4 17 79 E2 79 ..:. ..t..y.y
[01F0] A7 41 0D 2D A6 09 C5 DF 9F 85 C4 C8 E8 28 10 23 .A.- .(.#
[0200] B2 87 1C 8F 82 3E EC F6 BB 51 49 CD EF CF D3 95 .>.. .QI.
[0210] 76 E5 A1 7B 6D 42 81 04 81 8D C0 9C 82 13 14 A1 v..{mB..
[0220] 1C 8B B1 ED 94 D7 41 EF 43 04 49 A5 35 17 17 51 ..A. C.I.5..Q
[0230] C1 D0 27 13 93 6F CF 15 15 E6 C3 32 4D 85 9D E7 ..'..o.. ...2M...
[0240] FF E7 36 D9 3F CE 35 A2 DC 2D AB 06 1E 84 2B 6E ..6.?.5. .-+n
[0250] 3C D9 BF 3E 01 9E 6B 8B 5D 8D F3 98 F0 AA 1B 62 <..>..k. ]..b
[0260] C4 BD D9 CB F6 F8 77 60 09 3C F1 C7 9B FA BB 6C ..w` .<.l
[0270] CF A8 6E 7C 6B 4B 20 D3 FB 1A 83 16 CC E1 2C 8D ..n|kK . ..,.
[0280] 1F C0 6C 8F 93 69 7F 24 2C B4 76 9E D4 5E 2D 60 ..l..i.$ ,.v..^-`
[0290] 38 3D 72 D6 07 E0 38 81 52 F1 71 06 23 07 68 18 8=r...8. R.q.#.h.
[02A0] 67 7B D5 56 6B 19 E8 EF 7C 45 BB B3 7C A1 45 71 g{.Vk... |E..|.Eq
[02B0] 1C 2B 27 8D 2D B0 7D 6C 0B 1E 4A 0F EC 39 C0 80 .+'.-.}l ..J..9..
[02C0] D5 3F A6 A9 01 96 BE 95 D9 8F 79 3C 9B E2 B5 77 .?.. ..y<...w
[02D0] 68 BA 2B B3 F4 53 70 71 3C 78 FC 12 D5 09 3B 4F h.+..Spq . :...
num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0,
data_total=1272, this_data=1272, max_data=4280, param_offset=84,
param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0
smb_signing_md5: sequence number 16
smb_signing_sign_pdu: sent SMB signature of
[] 22 D2 88 02 E7 0E C2 30"..0
smb_signing_md5: sequence number 17
smb_signing_check_pdu: seq 17: got good SMB signature of
[] C7 4B 3C 94 92 8D 79 5F.K<...y_
rpc reply data:
[] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[0010] 00 00 00 00 35 00 00 C05...
[Wed Mar 18 11:18:04.781985 2015] [:error] [pid 3831] ipa: INFO:
[jsonserver_session] ad...@solaris.com: trust_add(u'infra.com',
trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'',
all=False, raw=False, version=u'2.113'): RemoteRetrieveError
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771",
On Wed, 18 Mar 2015, Ben .T.George wrote: HI i saw this ticket and' 13 months old https://fedorahosted.org/freeipa/ticket/4202 is this fixed? i think the mentioned patch is for 3.3 This is fixed. Do you have any host in .solaris.com that is joined your AD in infra.com? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771",
On Wed, 18 Mar 2015, Ben .T.George wrote: no, this is new host-name i am choosed. anyway how to check is there any existing solaris.com in AD, under DNS management, i cannot see anything You can search with ldapsearch, something like this, from IPA master: ldapsearch -D administra...@infra.com -W -b dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771",
On Wed, 18 Mar 2015, Ben .T.George wrote: did that and the result is [root@kwtpocpbis02 ~]# ldapsearch -D administra...@infra.com -W -b dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn Enter LDAP Password: ldap_bind: No such object (32) You have new mail in /var/spool/mail/root Ah, sorry, you need to add -h option to specify LDAP server host (your AD DC). On Wed, Mar 18, 2015 at 12:59 PM, Alexander Bokovoy wrote: On Wed, 18 Mar 2015, Ben .T.George wrote: no, this is new host-name i am choosed. anyway how to check is there any existing solaris.com in AD, under DNS management, i cannot see anything You can search with ldapsearch, something like this, from IPA master: ldapsearch -D administra...@infra.com -W -b dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn -- / Alexander Bokovoy -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771",
On Wed, 18 Mar 2015, Ben .T.George wrote: ok thanks now the output is something different [root@kwtpocpbis02 ~]# ldapsearch -h 172.16.107.250 -D administra...@infra.com -W -b dc=infra,dc=com '(serviceprincipalname=* solaris.com)' dn Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (serviceprincipalname=*solaris.com) # requesting: dn # # search reference ref: ldap://ForestDnsZones.infra.com/DC=ForestDnsZones,DC=infra,DC=com # search reference ref: ldap://DomainDnsZones.infra.com/DC=DomainDnsZones,DC=infra,DC=com # search reference ref: ldap://infra.com/CN=Configuration,DC=infra,DC=com # search result search: 2 result: 0 Success # numResponses: 4 # numReferences: 3 You have new mail in /var/spool/mail/root but there is no solaris.com in this output Ok. Send me privately error_log after 'ipa trust-add'. Don't forget to set 'log level = 100' in /usr/share/ipa/smb.conf.empty before doing that. On Wed, Mar 18, 2015 at 1:38 PM, Alexander Bokovoy wrote: On Wed, 18 Mar 2015, Ben .T.George wrote: did that and the result is [root@kwtpocpbis02 ~]# ldapsearch -D administra...@infra.com -W -b dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn Enter LDAP Password: ldap_bind: No such object (32) You have new mail in /var/spool/mail/root Ah, sorry, you need to add -h option to specify LDAP server host (your AD DC). On Wed, Mar 18, 2015 at 12:59 PM, Alexander Bokovoy wrote: On Wed, 18 Mar 2015, Ben .T.George wrote: no, this is new host-name i am choosed. anyway how to check is there any existing solaris.com in AD, under DNS management, i cannot see anything You can search with ldapsearch, something like this, from IPA master: ldapsearch -D administra...@infra.com -W -b dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn -- / Alexander Bokovoy -- / Alexander Bokovoy -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] sssd options ignored?
On Wed, 18 Mar 2015, Gould, Joshua wrote: On 3/18/15, 4:28 AM, "Alexander Bokovoy" wrote: On Wed, 18 Mar 2015, Gould, Joshua wrote: I¹ll be happy to remove the AD section from the sssd.conf file and test but I think there¹s more going on. The AD section was generated from the IPA client install. I never manually added anything other than ³pac² to the services line under the [sssd] section and the two ldap_idmap_range options. Show your /var/log/ipaclient-install.log. ipa-client-install has no support to generate sections for AD at all. I think then it would have to be the “ipa trust-add” command which generates those sections then? The command that I used was: No, it is not. We don't have *any* code that could have generated that section in FreeIPA. # ipa trust-add --type=ad TEST.OSUWMC ―-admin=farus ―password --range-type=ipa-ad-trust Active Directory domain administrator's password: ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue The trust was created even with that error message and seems to work. Do you get something like $ kdestroy -A $ kinit admin $ kvno -S cifs $ klist -ef working? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID
On Wed, 18 Mar 2015, Guertin, David S. wrote: Wait, why do you have middlebury.edu section here at all? If middlebury is trusted by csns.middlebury.edu, you should not have a separate [domain/middlebury.edu] section at all! That was in there because in my increasingly desperate attempts to get this working, I actually read the documentation, and Section 2.4 of the RHEL 7 Windows Integration Guide says to create a new domain section for the Active Directory domain. Not knowing any better, I played along. I have removed that section, and now things are broken again. However, the "Could not convert objectSID to a UNIX ID" problem is solved -- it's now breaking elsewhere, but I don't know where yet. I've set debug_level = 10 everywhere, and don't see anything but success messages in the logs, until the user is disconnected. I should probably start another thread for that. Yes, separating the issues would be better because we have more and more people trying to follow threads in email archive in search of solutions to their problems. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD users cannot log in: PAM permission denied
On Wed, 18 Mar 2015, Guertin, David S. wrote:
I've almost got AD integration going, except for the minor detail that no one
can log in. When an AD user tries to SSH in to the IPA server, /var/log/secure
shows:
--
Mar 18 13:59:08 genet sshd[21335]: pam_unix(sshd:auth): authentication failure;
logname= uid=0 euid=0 tty=ssh ruser= rhost=tundra.middlebury.edu
user=MIDD\guertin-s
Mar 18 13:59:09 genet sshd[21335]: pam_sss(sshd:auth): authentication success;
logname= uid=0 euid=0 tty=ssh ruser= rhost=tundra.middlebury.edu
user=MIDD\guertin-s
Mar 18 13:59:10 genet sshd[21335]: pam_sss(sshd:account): Access denied for
user MIDD\guertin-s: 6 (Permission denied)
Mar 18 13:59:10 genet sshd[21335]: Failed password for MIDD\\guertin-s from
140.233.6.66 port 59707 ssh2
Mar 18 13:59:10 genet sshd[21335]: fatal: Access denied for user
MIDDguertin-s by PAM account configuration [preauth]
--
So pam_sss is responding with "permission denied".
pam_sss verifies your right to access a service by seeing if there is an
HBAC rule that allows it. HBAC rules are to allow what is denied by
default.
In standard FreeIPA setup we have 'allow_all' HBAC rule which roughly
states "anyone can access any service on any host". Did you disable this
rule?
If yes, then you have to have an explicit rules allowing access to
specific services.
See examples in 'ipa trust' and 'ipa hbacrule'. Without arguments any
topic level command in IPA CLI prints a help, there are examples of use
of commands from those topics.
To create HBAC rules for AD users you first need to create a grouping
for them in IPA ('ipa trust' has explicit example how to do that) and
then define an HBAC rule to allow that POSIX group to access sshd
service.
HBAC services are PAM service names (i.e. /etc/pam.d/).
Everything looks normal here to me, until "[pam_dp_process_reply]
(0x0100): received: [6]", after which the client disconnects. Can
someone help with PAM configuration to get this to work?
As described in the documentation, my ad_users group contains the group
ad_users_external, which contains the AD group rhidm_users:
# ipa group-show ad_users
Group name: ad_users
Description: AD users
GID: 144725
Member groups: ad_users_external
# ipa group-show ad_users_external
Group name: ad_users_external
Description: AD users external map
Member of groups: ad_users
External member: rhidm_us...@middlebury.edu?
Right, so you have ad_users group now and need to define an HBAC rule
allowing it an access to sshd service.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Minimum rights to enrol a client
On Fri, 20 Mar 2015, David Kupka wrote:
On 03/20/2015 09:16 AM, Andrew Holway wrote:
Hello,
I'd like to find our what the minimum role would be to allow a user to join
a new client to freeipa.
Currently our enrol command looks like:
ipa-client-install --force-join --enable-dns-updates -U -p admin -w
:
Thanks,
Andrew
Hello!
AFAIK there is 'Host Enrollment' privilege created during IPA server
installation. You need to create new role and add this privilege to
the newly created role.
The role can then be assigned to any user or group. User with this
privilege have enough permissions to enroll a host to IPA domain.
That is not a full story.
To enroll hosts you have to have 'Host Enrollment' privilege but this
privilege does not give you rights to create a host object. Creating
hosts is a separate permission ('System: Add Hosts') granted to a
separate privilege, 'Host Administrators'.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
24.368506: Request or response is too big for UDP; retrying with TCP >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 >> [12299] 1426773524.384237: Response was not from master KDC >> [12299] 1426773524.384263: Processing preauth types: 19 >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >> [12299] 1426773524.384275: Produced preauth for next request: (empty) >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB >> [12299] 1426773524.384333: FAST negotiation: unavailable >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ bpr...@example.corp >> [12299] 1426773524.384400: Removing bpr...@example.corp -> krbtgt/example.c...@example.corp from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384407: Storing bpr...@example.corp -> krbtgt/example.c...@example.corp in KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/example.c...@example.corp: pa_type: 2 >> [12299] 1426773524.384484: Removing bpr...@example.corp -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP@X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384492: Storing bpr...@example.corp -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP@X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> Any ideas? > >Can you log in to the IPA server as this user? If yes I would assume >that the password gets garbled somewhere on the way from AIX through the >IPA machinery to SSSD. Does the password contain some special characters >which some LDAP processing calls might want the escape? > >bye, >Sumit > Yes, I can login with the account on the IPA server without any problems. I tried it with different password to rule out problems with special characters. Finally I did a tcpdump on the IPA server. The AIX server sends the word 'INCORRECT' to the IPA server instead of the password. So I guess I have to do some more configuration checks on the AIX server. Thank you for the feedback. Just a wild guess, since you were able to see anything in the tcpdump I guess an unencrypted connection is used. Maybe AIX prevents that the password is send via a clear text connection? It is openssh behavior. It sends INCORRECT line as part of the password when there is no valid shell for that user to login. OpenSSH validates content of 'struct passwd' returned for the user, including checks on whether shell is there as an executable file. This check fails and user is considered 'invalid'. Still, OpenSSH competes PAM authentication, making sure the password field is filled with specially constructed string "\b\n\r\177INCORRECT", to ensure there is registered failed login attempt. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
om KDC: -1765328332/Response too big for UDP, retry with TCP >> [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 >> [12299] 1426773524.384237: Response was not from master KDC >> [12299] 1426773524.384263: Processing preauth types: 19 >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >> [12299] 1426773524.384275: Produced preauth for next request: (empty) >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB >> [12299] 1426773524.384333: FAST negotiation: unavailable >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ bpr...@example.corp >> [12299] 1426773524.384400: Removing bpr...@example.corp -> krbtgt/example.c...@example.corp from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384407: Storing bpr...@example.corp -> krbtgt/example.c...@example.corp in KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/example.c...@example.corp: pa_type: 2 >> [12299] 1426773524.384484: Removing bpr...@example.corp -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP@X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384492: Storing bpr...@example.corp -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP@X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> Any ideas? > >Can you log in to the IPA server as this user? If yes I would assume >that the password gets garbled somewhere on the way from AIX through the >IPA machinery to SSSD. Does the password contain some special characters >which some LDAP processing calls might want the escape? > >bye, >Sumit > Yes, I can login with the account on the IPA server without any problems. I tried it with different password to rule out problems with special characters. Finally I did a tcpdump on the IPA server. The AIX server sends the word 'INCORRECT' to the IPA server instead of the password. So I guess I have to do some more configuration checks on the AIX server. Thank you for the feedback. Just a wild guess, since you were able to see anything in the tcpdump I guess an unencrypted connection is used. Maybe AIX prevents that the password is send via a clear text connection? It is openssh behavior. It sends INCORRECT line as part of the password when there is no valid shell for that user to login. OpenSSH validates content of 'struct passwd' returned for the user, including checks on whether shell is there as an executable file. This check fails and user is considered 'invalid'. Still, OpenSSH competes PAM authentication, making sure the password field is filled with specially constructed string "\b\n\r\177INCORRECT", to ensure there is registered failed login attempt. Wow, thanks for that! If I do a lsuser/ldapsearch on the AIX host the shell/loginShell is missing for AD users. The admin IPA user has this attribute set and I can log in with that account. Can this be solved on the IPA server? In FreeIPA 4.1 (Fedora 21+ or RHEL7.1) you can do set shell separately for each AD user using ID Views: ipa idoverrideuser-add 'Default Trust View' 'AD\User' --shell /bin/ksh Compat tree and SSSD on RHEL7.1/Fedora21 should take default trust view into account for AD users. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
On Mon, 23 Mar 2015, Bobby Prins wrote: On 03/20/2015 08:05 AM, Alexander Bokovoy wrote: On Fri, 20 Mar 2015, Bobby Prins wrote: On Fri, 20 Mar 2015, Sumit Bose wrote: On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >> Hi there, >> >> I'm currently trying to use the 'AD Trust for Legacy Clients' >> freeIPA setup (described here: >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) >> to be able to autenticate AIX 7.1 clients against an AD domain >> using LDAP. After the trust was created all seems to work well >> on the freeIPA server. I can also do a lookup of AD users and >> groups on an AIX test server. >> >> But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for bpr...@example.corp >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775 [k5c_send_data] (0x0200): Received error code 1432158214 >> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit bpr...@example.corp': >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> [12299] 1426773524.361880: Produced preauth for next request: 2 >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >> [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 >> [12299] 1426773524.368482: Response was not from master K
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
On Tue, 24 Mar 2015, Bobby Prins wrote: - Oorspronkelijk bericht - Van: "Alexander Bokovoy" Aan: "Bobby Prins" Cc: d...@redhat.com, freeipa-users@redhat.com Verzonden: Maandag 23 maart 2015 16:44:47 Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode ... Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access and sssd logs from IPA master (with debug_level = 10) at least in [domain], [nss], and [pam] sections. You need to filter dirsrv logs by connection coming from AIX IP address and then by conn= where number is the same number as the one with IP address line. When authenticating, AIX would talk to IPA LDAP server to compat tree and slapi-nis plugin which serves compat tree would do PAM authentication as service system-auth where SSSD on IPA master will do the actual authentication work. -- / Alexander Bokovoy Here you can see the DS connection from AIX: [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bpr...@example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bpr...@example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 As you can see it also takes quite some time to process the login. Could that be a problem? 24 seconds sounds like bprins2example.com is a member of few groups with big amount of members. On the other hand, BIND operation result is 0 (success) and it doesn't look like AIX dropped the connection, at least there is no ABANDON within the context of this connection so AIX did not cancel the request by itself. How long does it take on AIX side to report the inability to login? Is this time longer or shorter the one reported in etime= value on RESULT line above? The SSSD log files are a bit large with debug_level set to 10 and it will take me some time to strip all customer data from it. Any log events in particular you would like to see? https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for some times of issues you might find in the SSSD logs. I'd be interested in "Common AD provider issues", "Troubleshooting authentication, password change and access control". -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
On Tue, 24 Mar 2015, Bobby Prins wrote: - Oorspronkelijk bericht - Van: "Alexander Bokovoy" Aan: "Bobby Prins" Cc: d...@redhat.com, freeipa-users@redhat.com Verzonden: Dinsdag 24 maart 2015 15:13:38 Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode On Tue, 24 Mar 2015, Bobby Prins wrote: - Oorspronkelijk bericht - Van: "Alexander Bokovoy" Aan: "Bobby Prins" Cc: d...@redhat.com, freeipa-users@redhat.com Verzonden: Maandag 23 maart 2015 16:44:47 Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode ... Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access and sssd logs from IPA master (with debug_level = 10) at least in [domain], [nss], and [pam] sections. You need to filter dirsrv logs by connection coming from AIX IP address and then by conn= where number is the same number as the one with IP address line. When authenticating, AIX would talk to IPA LDAP server to compat tree and slapi-nis plugin which serves compat tree would do PAM authentication as service system-auth where SSSD on IPA master will do the actual authentication work. -- / Alexander Bokovoy Here you can see the DS connection from AIX: [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bpr...@example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bpr...@example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 As you can see it also takes quite some time to process the login. Could that be a problem? 24 seconds sounds like bprins2example.com is a member of few groups with big amount of members. On the other hand, BIND operation result is 0 (success) and it doesn't look like AIX dropped the connection, at least there is no ABANDON within the context of this connection so AIX did not cancel the request by itself. How long does it take on AIX side to report the inability to login? Is this time longer or shorter the one reported in etime= value on RESULT line above? The SSSD log files are a bit large with debug_level set to 10 and it will take me some time to strip all customer data from it. Any log events in particular you would like to see? https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for some times of issues you might find in the SSSD logs. I'd be interested in "Common AD provider issues", "Troubleshooting authentication, password change and access control". -- / Alexander Bokovoy The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. PAM logging on AIX: Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bpr...@example.corp) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt fo
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
On Tue, 24 Mar 2015, Bobby Prins wrote: The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. PAM logging on AIX: Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bpr...@example.corp) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER Doing a ldapsearch with bpr...@example.corp as bind user works without any problems. According to the log above you get failure from pam_aix which should be expected if pam_aix doesn't think that the user in question is coming from LDAP. Can you show output of lsuser -R LDAP bpr...@example.corp lsuser -a registry SYSTEM bpr...@example.corp The attributes 'registry' and 'SYSTEM' should be set to LDAP (or KRB5LDAP). Can you show how you configured the AIX client? -- / Alexander Bokovoy lsuser -R LDAP bpr...@example.corp: bpr...@example.corp id=211623277 pgrp=bpr...@example.corp groups=bpr...@example.corp home=/home/example.corp/bprins shell=/bin/bash gecos=Bobby Prins login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=LDAP SYSTEM=LDAP logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minloweralpha=0 minupperalpha=0 minother=0 mindigit=0 minspecialchar=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=8388604 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles= I assume you have /bin/bash installed on AIX? This user has shell defined as /bin/bash and if it is missing, login or ssh will deny its access to the system. lsuser -a registry SYSTEM bpr...@example.corp: bpr...@example.corp registry=LDAP SYSTEM=LDAP Contents of /etc/security/ldap/ldap.cfg: ldapservers:idm01.unix.example.corp authtype:ldap_auth useSSL:no userattrmappath:/etc/security/ldap/IPAuser.map groupattrmappath:/etc/security/ldap/IPAgroup.map userbasedn:cn=users,cn=compat,dc=unix,dc=example,dc=corp groupbasedn:cn=groups,cn=compat,dc=unix,dc=example,dc=corp userclasses:posixaccount groupclasses:posixgroup ldapport:389 searchmode:ALL defaultentrylocation:LDAP serverschematype:rfc2307 Map file /etc/security/ldap/IPAuser.map: #IPAuser.map file keyobjectclass SEC_CHARposixaccounts # The following attributes are required by AIX to be functional usernameSEC_CHARuid s id SEC_INT uidnumber s pgrpSEC_CHARgidnumber s homeSEC_CHARhomedirectory s shell SEC_CHARloginshell s gecos SEC_CHARgecos s spassword SEC_CHARuserpasswords lastupdate SEC_INT shadowlastchanges Map file /etc/security/ldap/IPAgroup.map: #IPAgroup.map file groupname SEC_CHARcns id SEC_INT gidNumber s users
Re: [Freeipa-users] Is it possible to Disable "BAD Password" from IPA Configs
On Wed, 25 Mar 2015, Yogesh Sharma wrote: Hi, Is there any way that we can configure IPA server not to do Strict Checking for Password. For EG: *BAD PASSWORD: The password is too similar to the old one* *New password: * *BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word* We tried removing "use_authtok" from below but no luck. passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok You are changing *wrong* configuration. system-auth "password" config: [root@cipa vagrant]# cat /etc/pam.d/system-auth | grep password | grep -v grep *passwordrequisite pam_pwquality.so try_first_pass retry=3 type=* pam_pwquality is responsible for the password strength checks in PAM stack. Read its documentation for details. P.S. This question has nothing to do with FreeIPA. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AIX client integration
On Thu, 26 Mar 2015, David Beck wrote: All, This for anyone using AIX clients with freeipa. I have the client up and running just fine (No KRB5, AIX Bug); however I cannot seem to get If you mean inability to use GSSAPI authentication against LDAP, it is not a bug in AIX. Rather, it is a bug in CyrusSASL which is fixed in RHEL-6.6.z. We have plans to fix RHEL 7.x too but for your situation an update is going to help. https://rhn.redhat.com/errata/RHBA-2015-0721.html the client to load the groups attributes properly. The users primary group shows up in the groups attribute from lsuser but not any subsequent groups the user is a member of in IPA. In the outputs below, I do a lookup for IPA user 0016751and I would expect the groups= attirbute to match those that are listed in the "Member of Groups" from freeipa. I experiemented with the groups attribute and mapping to the memberOf ldap attribute in the IPAuser.map file but that hasn't changed the outcome. If anyone has any pointers or advice it would ge greatly appreciated! Use /var/log/dirsrv/slapd-ABC-COM/access to find out a connection corresponding to AIX operations around your lookups and show all lines with the same conn= element. Ideally, it would help to get a network trace between AIX and IPA LDAP server. Given that you are not using SASL GSSAPI and SSL, it should be easy to see what exactly is requested by AIX and returned by IPA LDAP. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Unexpired pw?
On Fri, 27 Mar 2015, Janelle wrote: Hi all, Found an odd issue and a question. If you change user pw with "ipa user-mod -password" and the client is configured for LDAP, then the user is not forced to change the pw on initial login. We have three different cases depending on who changes userPassword attribute in LDAP: 1. cn=Directory Manager can change anything and it doesn't taint the userPassword. 2. A user can change own password and it doesn't taint the userPassword attribute. 3. Any other identity that can change a password will taint userPassword attribute. If you change user password with "ipa user-mod --password" the question should be "who are you?" and the answer to that question drives the tainting logic described above. However, my other question is, can you set a user pw WITHOUT pre-expiring?! cn=Directory manager is the one who can but directly in LDAP as you cannot authenticate as 'cn=Directory manager' using IPA tools. If you are insisting on lowering security of your passwords, nothing prevents you from changing user password to some value as admin user first and then setting it as that user to a correct value. We don't recommend to do so but you have means already to ignore our recommendations. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA with Active directory Read-only domain controller trust setup
On Tue, 31 Mar 2015, Petr Spacek wrote: On 30.3.2015 18:00, Dmitri Pal wrote: On 03/30/2015 11:12 AM, Srdjan Dutina wrote: Hi, I'm testing FreeIPA (v4.1.3, Centos 7) - AD (2012 R2) trust on branch site where only AD read-only domain controller (RODC) exists. I'm aware that for initial establishing of trust I need access to writable domain controller so IPA can add trust to AD domains and trusts. But after initial setup, can FreeIPA-AD trust continue to function with IPA access to RODC only? Should work. Will Kerberos authentication of AD users on IPA domain hosts work? In this case, FreeIPA server should have DNS forward zone configured with RODC as a forwarder to AD? It should not matter as long as the forwarder knows how to resolve all the DNS names. General advice is to pick nearest server if you have access to it and add couple other servers to enable fail-over (if the nearest server fails for some reason). In general, user identity lookup for trusted AD users happens via IPA masters -- each IPA client would delegate lookup to IPA master and that one would use closest site discovered in AD to do the lookup. With authentication we are in a bit more complex situation. GSSAPI authentication assumes your Windows client comes already with a service ticket to an IPA client's service. The ticket is obtained by Windows client by first obtaining cross-realm TGT from AD DC and then using this TGT to ask for a service ticket from IPA master (KDC). The latter ticket is then presented to an IPA client's service. When AD user attempts to use their password directly, IPA client will be talking to a discovered AD DC to validate the password and authenticate the user. At this step discovery of AD DC for Kerberos purposes is not done based on site locality, SSSD still has some open ticket to do that if I remember correctly. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa 4.x packages for RHEL?
On Tue, 31 Mar 2015, Steve Neuharth wrote: Hello, We're currently running RHEL in production and would love to be using all the goodness that is FreeIPA 4 including certmonger for certificate management. I don't see any mention of 4.x packages available for RHEL in the mailing lists and I have run into problems using the 3.3 client packages on a 4.x realm. When will 4.x packages be available for RHEL? They are already available, starting with RHEL7.1. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] OTP integrations
On Tue, 31 Mar 2015, Dmitri Pal wrote: On 03/31/2015 05:30 PM, Andrew Holway wrote: Hello FreeIPA people, I must say that FreeIPA v4 looks very pretty and I am looking forward to trying out the new features. I'm wondering what application and tools can be used to authenticate with the OTP in freeipa. For instance, if we wanted to set up a VPN that uses it how might we go about that? Is there a common library that I should look out for? With VPN you usually do the following: a) Pick a VPN of your choice based on features and needs you have b) Make sure the VPN server supports different authentication methods. You need at least RADIUS which is the most popular option and I would be surprise to find VPN server that does not talk RADIUS to actually do the authentication. c) Setup freeRADIUS server on Fedora 21/RHEL 7.1/Centos 7.1 (when it happens) box , configure it to do kinit authentication or pam authentication via SSSD against IPA, see freeRADIUS manuals for more details d) Connect VPN server to the RADIUS server e) Provision tokens (or hook IPA to existing OTP solution using another RADIUS server) f) Profit If you have an application that can use RADIUS in such setup you can use FreeIPA 2FA. Also see http://www.freeipa.org/page/Web_App_Authentication how to enable any web application to take advantage of the IPA authentication including 2FA. It is simple to configure OpenVPN with authentication against FreeIPA in Fedora 21, all the heavy lifting is done by SSSD: # grep plugin /etc/openvpn/server.conf plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so "openvpn login USERNAME password PASSWORD" # LANG=C ls -l /etc/pam.d/openvpn lrwxrwxrwx. 1 root root 11 Apr 1 10:55 /etc/pam.d/openvpn -> system-auth # LANG=C ipa user-show vpnuser User login: vpnuser First name: VPN Last name: TestUser Home directory: /home/vpnuser Login shell: /bin/sh Email address: vpnu...@example.com UID: 179265 GID: 179265 Account disabled: False User authentication types: otp Password: True Member of groups: ipausers Kerberos keys available: True Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: received command code: 0 Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: USER: vpnuser Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: my_conv[0] query='login:' style=2 Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: name match found, query/match-string ['login:', 'login'] = 'USERNAME' Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: my_conv[0] query='Password: ' style=1 Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: name match found, query/match-string ['Password: ', 'password'] = 'PASSWORD' Apr 01 11:24:50 ipa.example.com openvpn[29724]: pam_unix(openvpn:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=vpnuser Apr 01 11:24:53 ipa.example.com openvpn[29724]: pam_sss(openvpn:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=vpnuser Apr 01 11:24:55 ipa.example.com openvpn[29732]: MY-IP_ADDRESS:50232 PLUGIN_CALL: POST /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0 Apr 01 11:24:55 ipa.example.com openvpn[29732]: MY-IP-ADDRESS:50232 TLS: Username/Password authentication succeeded for username 'vpnuser' -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] where to disable components?
On Tue, 31 Mar 2015, Janelle wrote: Hello again... Looking around, but probably just not in the right place. I would like to be able to disable httpd on all but a pair of servers, so we kind of force all updates to come from a "master" and "slave" pair. Just trying to keep updates defined to 2 servers rather than all of them in an 8 server configuration. Where might I find that? Or is it possible? Will it break anything? You wouldn't get anything by doing such a selecting 'disabling'. Every Kerberos authentication causes updates of LDAP objects on the KDC, so if you have 8 KDCs, all of them will be modifying LDAP store and replicating to each other. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] OTP integrations
On Wed, 01 Apr 2015, Andrew Holway wrote: Please could someone explain to me what is happening internally? In my head I have the following process The openvpn pam module sends the username and password to pam. Pam passes this onto sssd sssd then does the kerberos thing kerberos passes the password to the LDAP KDC passes request to ipa-otpd daemon (our RADIUS-like proxy) which then binds to IPA LDAP to verify the password some LDAP module takes the password from the database, appends on the OTP and actually does the auth... Yes, the rest is correct. http://www.freeipa.org/images/d/d1/FreeIPA_OTP.png is the full picture from on "the Kerberos thing" On 1 April 2015 at 13:15, Andrew Holway wrote: It is simple to configure OpenVPN with authentication against FreeIPA in Fedora 21, all the heavy lifting is done by SSSD: I have to say that this sssd / pam method is working very very well. I do however need to get my head around radius. Something for a rainy sunday I think :). # grep plugin /etc/openvpn/server.conf plugin /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so "openvpn login USERNAME password PASSWORD" # LANG=C ls -l /etc/pam.d/openvpn lrwxrwxrwx. 1 root root 11 Apr 1 10:55 /etc/pam.d/openvpn -> system-auth # LANG=C ipa user-show vpnuser User login: vpnuser First name: VPN Last name: TestUser Home directory: /home/vpnuser Login shell: /bin/sh Email address: vpnu...@example.com UID: 179265 GID: 179265 Account disabled: False User authentication types: otp Password: True Member of groups: ipausers Kerberos keys available: True Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: received command code: 0 Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: USER: vpnuser Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: my_conv[0] query='login:' style=2 Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: name match found, query/match-string ['login:', 'login'] = 'USERNAME' Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: my_conv[0] query='Password: ' style=1 Apr 01 11:24:50 ipa.example.com openvpn[29723]: AUTH-PAM: BACKGROUND: name match found, query/match-string ['Password: ', 'password'] = 'PASSWORD' Apr 01 11:24:50 ipa.example.com openvpn[29724]: pam_unix(openvpn:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=vpnuser Apr 01 11:24:53 ipa.example.com openvpn[29724]: pam_sss(openvpn:auth): authentication success; logname= uid=0 euid=0 tty= ruser= rhost= user=vpnuser Apr 01 11:24:55 ipa.example.com openvpn[29732]: MY-IP_ADDRESS:50232 PLUGIN_CALL: POST /usr/lib64/openvpn/plugins/openvpn-plugin-auth-pam.so/ PLUGIN_AUTH_USER_PASS_VERIFY status=0 Apr 01 11:24:55 ipa.example.com openvpn[29732]: MY-IP-ADDRESS:50232 TLS: Username/Password authentication succeeded for username 'vpnuser' -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL 5 client?
On Wed, 01 Apr 2015, Guertin, David S. wrote: The 5.x ipa-client should work fine. What isn't working? I cannot SSH in as an AD user. (Sorry, I should have mentioned that in my original post.) The client installs without errors, and I can get a Kerberos ticket for the admin user. But when I try to SSH in as an AD domain user, the login fails: $ ssh -l 'MIDD\juser' yakko.ipa Red Hat Enterprise Linux Server release 5.11 (Tikanga) Kernel 2.6.18-402.el5 on an x86_64 Password: Password: Password: MIDD\ju...@yakko.ipa's password: Received disconnect from 140.233.1.100: 2: Too many authentication failures for MIDD\\juser And on the client, with debug_level = 10 for sssd, /var/log/sssd/sssd_nss.log shows: (Wed Apr 1 14:24:03 2015) [sssd[nss]] [sss_ncache_set_str] (6): Adding [NCE/USER/ipa.middlebury.edu/MIDD\juser] to negative cache (Wed Apr 1 14:24:03 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (2): No results for getpwnam call (Wed Apr 1 14:24:03 2015) [sssd[nss]] [sss_dp_req_destructor] (8): Could not clear entry from request queue (Wed Apr 1 14:24:03 2015) [sssd[nss]] [reset_idle_timer] (9): Idle timer re-set for client [0x1aeec870][17] (Wed Apr 1 14:24:03 2015) [sssd[nss]] [reset_idle_timer] (9): Idle timer re-set for client [0x1aeec870][17] (Wed Apr 1 14:24:03 2015) [sssd[nss]] [reset_idle_timer] (9): Idle timer re-set for client [0x1aeec870][17] (Wed Apr 1 14:24:03 2015) [sssd[nss]] [nss_cmd_getpwnam] (4): Requesting info for [MIDD\juser] from [] (Wed Apr 1 14:24:03 2015) [sssd[nss]] [sss_ncache_check_str] (8): Checking negative cache for [NCE/USER/ipa.middlebury.edu/MIDD\juser] (Wed Apr 1 14:24:03 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (2): User [MIDD\juser] does not exist in [ipa.middlebury.edu]! (negative cache) (Wed Apr 1 14:24:03 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (2): No matching domain found for [MIDD\juser], fail! There's a trust relationship set up between the IPA domain and the AD domain, but it's like the RHEL 5 client doesn't know about it. Did I miss something? Show your sssd.conf. Practically, in order to provide access to RHEL5 systems for AD users, you need to configure sssd on RHEL5 against compat tree on IPA LDAP. More to that, we had few bugs that prevented successful authentication to complete from older clients against compat tree. These bugs are fixed as part of RHEL7.1 update 1 cumulative release. A typical RHEL5 configuration script can be obtained by running 'ipa-advise config-redhat-sssd-before-1-9' on IPA master. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Openvpn and Certificates
On Wed, 01 Apr 2015, Andrew Holway wrote: On 1 April 2015 at 20:02, Nalin Dahyabhai wrote: On Wed, Apr 01, 2015 at 07:02:56PM +0200, Andrew Holway wrote: > I understand from previous discussions that client certificates are not yet > supported in FreeIPA, instead I understand one can use "service > certificates". From an OpenVPN standpoint I'm guessing this is fine because > a vpn client can be entered in Freeipa as a client and a certificate > generated for it. This might actually be a preferred model for VPN. > > My OVPN server config looks like this: > ca ca.crt > cert server.crt > key server.key > # Diffie hellman parameters. > dh dh2048.pem > > I guess I can use the > "ipa-getcert request -f /path/to/server.crt -k /path/to/private.key -r" > command to generate the server.crt and private.key and I know where to find > ca.crt however: Unless there are other requirements on the contents of the certificate, I'd expect that to work. ipa service-add-host --hosts ipa.domain.de client/ andrews-macbook-air.local.domain.de ipa-getcert request -f /var/lib/certmonger/requests/Andrews-MacBook-Air.local.crt -k /var/lib/certmonger/requests/Andrews-MacBook-Air.local.key -N CN= andrews-macbook-air.local.domain.de -D andrews-macbook-air.local.domain.de -K client/andrews-macbook-air.local.domain...@domain.de -- Then shuffle the keys and certs around -- -- Restart OpenVPN -- And et voila! It works! Although it does feel a bit hacky :) I do it the same way as I control my systems and can be sure there is one user per system for VPN access. Works nicely. The only issue if you want some systems authenticate with certificates only and others with user/password+OTP. Unfortunately, this combination does not work with OpenVPN as all authentication methods must succeed. There is an option --auth-user-pass-optional that allows core OpenVPN to work without the requirement of passwords but then plugins/scripts must account for it and openvpn-plugin-auth-pam is not aware of that, it seems. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Openvpn and Certificates
On Thu, 02 Apr 2015, Andrew Holway wrote: And et voila! It works! Although it does feel a bit hacky :) I do it the same way as I control my systems and can be sure there is one user per system for VPN access. Works nicely. Is it possible to manage key revocation? I understand that this mechanism is mostly quite broken. How long are you making Certificates valid for? Standard mechanism works fine -- 'ipa cert-revoke'. However, you need to deliver CRL to OpenVPN server because OpenVPN only supports checking CRL from a file system. Theoretically one could make a systemd socket unit that would use 'nc' and curl to pick up CRL from a CA every time OpenVPN asks for it (on each client connection) or provide a cached version of it. An easiest way is to make CRL retrieval periodical and populate whatever directory or file crl-verify is pointed to. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Openvpn and Certificates
On Thu, 02 Apr 2015, Andrew Holway wrote: Is it possible to generate certs without the host having an entry in the DNS? Yes. Create a host with 'ipa host-add --force' and then use normal ways to generate certificates for this host. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL 5 client?
On Thu, 02 Apr 2015, Guertin, David S. wrote: Can you try searching the compat tree with ldapsearch to see if an entry turns up? IIRC you need to search for a particular entry, not for any (not ie cn=*), but if you crank up the debug_level in the domain section, then sssd should log the searches to /var/log/sssd/sssd_default.log Here's the result of ldapsearch on the RHEL 5 client (the same command works on RHEL 6): # ldapsearch -h middlebury.edu -p 389 -D 'MIDD\admin' -W -b "dc=middlebury,dc=edu" -s sub "cn=juser,cn=users,dc=middlebury,dc=edu" Enter LDAP Password: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No credentials cache found) This is wrong use of ldapsearch -- if you are using simple bind, make sure you tell ldapsearch about it. However, I'm not sure what you wanted to show as both hostname and base DN are different from what SSSD tries in the logs below. Also, unlike Active Directory, IPA LDAP does not (yet) accept short version of bind DN, you have to specify it fully. If you wanted to have Kerberos auth working on RHEL5, that is something that might or might not work for AD users depending on many circumstances, mostly related to the need to manually configure krb5.conf to know about AD realm and how to contact servers there but also due to possible issues with auth_to_local rulesets (if they even exist in that Kerberos library version). In case of AD users there is a sequence to follow for LDAP authentication if you want to repeat what SSSD does: 1. Search user with filter '(uid=username@domain)' to get the entry into compat tree. 2. Bind as uid=username@domain,cn=users,cn=compat,$BASEDN to trigger authentication check. This is how various LDAP-based NSS modules work, be it nss_ldap or pam-nss-ldapd, or SSSD. So, let's say, you have kerberos keytab with a host principal in /etc/krb5.keytba. The sequence to emulate what SSSD does would be kinit -k host/`hostname` ldapsearch -Y GSSAPI -H ldap://genet.ipa.middlebury.edu \ -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub \ '(uid=ad...@middlebury.edu)' As result, we have 'ad...@middlebury.edu' inserted in the compat tree, and can do a bind as 'uid=ad...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc=edu' ldapsearch -x -H ldap://genet.ipa.middlebury.edu \ -D 'uid=ad...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc=edu' \ -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub \ '(uid=ad...@middlebury.edu)' This would reproduce what SSSD was supposed to do. If you get these ldapsearches to work, we can look at what is SSSD doing. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
On Fri, 03 Apr 2015, Bobby Prins wrote: On Mar 24, 2015, at 17:11, Dmitri Pal wrote: Seems like 15 sec timeout on the AIX side. Can you try with a user that does not have that many groups and see if that works? If it does then we should assume it is an AIX side timeout and focus on making sure the data gets over to IPA within this timeout. I need to do some more testing.. Did not have a lot of time today, but I tried to authenticate with an AD user against the compact tree using a Linux client with pam_ldap. I was able to log in but this would take up to a minute or so. I’m still waiting for my AD test account with lesser group memberships. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. So I finally found some time to do extra tests. I now have an AD account with lesser group memberships which seems to speed up the login process (with Linux LDAP auth against the compat tree), but still no success on AIX. Did some more digging and it looks like AIX invalidates the user before it even is authenticated. The output below shows the lookup that is performed after I enter the username en press enter (before entering the password). access: [03/Apr/2015:11:58:47 +0200] conn=5950 fd=68 slot=68 connection from 192.168.140.107 to 192.168.140.133 [03/Apr/2015:11:58:47 +0200] conn=5950 op=0 BIND dn="" method=128 version=3 [03/Apr/2015:11:58:47 +0200] conn=5950 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [03/Apr/2015:11:59:04 +0200] conn=5950 op=1 SRCH base="cn=users,cn=compat,dc=unix,dc=example,dc=corp" scope=2 filter="(&(objectClass=posixaccount)(uid=bpr...@example.corp))" attrs=ALL [03/Apr/2015:11:59:04 +0200] conn=5950 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [03/Apr/2015:11:59:04 +0200] conn=5950 op=2 SRCH base="cn=users,cn=compat,dc=unix,dc=example,dc=corp" scope=2 filter="(&(objectClass=posixaccount)(uid=bprins))" attrs=ALL [03/Apr/2015:11:59:04 +0200] conn=5950 op=2 RESULT err=0 tag=101 nentries=0 etime=0 Above there are two lookups: - successful lookup for user bpri...@example.com - unsuccessful lookup for user bprins What is causing to perform a lookup without @example.com? Compat tree presents AD users fully qualified, it is the only way it knows to trigger lookup via SSSD on IPA master for these users (because non-fully qualified users are in IPA LDAP tree already and copied to compat tree automatically). -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode
On Fri, 03 Apr 2015, Bobby Prins wrote: - Oorspronkelijk bericht - Van: "Alexander Bokovoy" Aan: "Bobby Prins" Cc: d...@redhat.com, freeipa-users@redhat.com Verzonden: Vrijdag 3 april 2015 12:45:07 Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode On Fri, 03 Apr 2015, Bobby Prins wrote: On Mar 24, 2015, at 17:11, Dmitri Pal wrote: Seems like 15 sec timeout on the AIX side. Can you try with a user that does not have that many groups and see if that works? If it does then we should assume it is an AIX side timeout and focus on making sure the data gets over to IPA within this timeout. I need to do some more testing.. Did not have a lot of time today, but I tried to authenticate with an AD user against the compact tree using a Linux client with pam_ldap. I was able to log in but this would take up to a minute or so. I’m still waiting for my AD test account with lesser group memberships. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. So I finally found some time to do extra tests. I now have an AD account with lesser group memberships which seems to speed up the login process (with Linux LDAP auth against the compat tree), but still no success on AIX. Did some more digging and it looks like AIX invalidates the user before it even is authenticated. The output below shows the lookup that is performed after I enter the username en press enter (before entering the password). access: [03/Apr/2015:11:58:47 +0200] conn=5950 fd=68 slot=68 connection from 192.168.140.107 to 192.168.140.133 [03/Apr/2015:11:58:47 +0200] conn=5950 op=0 BIND dn="" method=128 version=3 [03/Apr/2015:11:58:47 +0200] conn=5950 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="" [03/Apr/2015:11:59:04 +0200] conn=5950 op=1 SRCH base="cn=users,cn=compat,dc=unix,dc=example,dc=corp" scope=2 filter="(&(objectClass=posixaccount)(uid=bpr...@example.corp))" attrs=ALL [03/Apr/2015:11:59:04 +0200] conn=5950 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [03/Apr/2015:11:59:04 +0200] conn=5950 op=2 SRCH base="cn=users,cn=compat,dc=unix,dc=example,dc=corp" scope=2 filter="(&(objectClass=posixaccount)(uid=bprins))" attrs=ALL [03/Apr/2015:11:59:04 +0200] conn=5950 op=2 RESULT err=0 tag=101 nentries=0 etime=0 Above there are two lookups: - successful lookup for user bpri...@example.com - unsuccessful lookup for user bprins What is causing to perform a lookup without @example.com? Compat tree presents AD users fully qualified, it is the only way it knows to trigger lookup via SSSD on IPA master for these users (because non-fully qualified users are in IPA LDAP tree already and copied to compat tree automatically). This seems to be (standard?) behaviour of the AIX LDAP client. Did some more tests with different accounts and always see the two lookups. I doubt if I can influence that.. No, this is not standard -- I haven't seen such behavior when testing FreeIPA with AIX last autumn. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL 5 client?
On Fri, 03 Apr 2015, Guertin, David S. wrote: The sequence to emulate what SSSD does would be kinit -k host/`hostname` ldapsearch -Y GSSAPI -H ldap://genet.ipa.middlebury.edu \ -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub \ '(uid=ad...@middlebury.edu)' As result, we have 'ad...@middlebury.edu' inserted in the compat tree, and can do a bind as 'uid=ad...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc =edu' ldapsearch -x -H ldap://genet.ipa.middlebury.edu \ -D 'uid=ad...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc =edu' \ -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub \ '(uid=ad...@middlebury.edu)' This would reproduce what SSSD was supposed to do. If you get these ldapsearches to work, we can look at what is SSSD doing. Thanks. Yes, both of those ldapsearch commands work. I can search for the user (I'm using a different user here): - # ldapsearch -Y GSSAPI -H ldap://genet.ipa.middlebury.edu -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub '(uid=ju...@middlebury.edu)' SASL/GSSAPI authentication started SASL username: host/yakko.ipa.middlebury@ipa.middlebury.edu SASL SSF: 56 SASL installing layers # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=ju...@middlebury.edu) # requesting: ALL # # ju...@middlebury.edu, users, compat, ipa.middlebury.edu dn: uid=ju...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc=edu objectClass: posixAccount objectClass: top cn: juser gidNumber: 435021613 gecos: juser uidNumber: 435021613 homeDirectory: /home/middlebury.edu/juser uid: ju...@middlebury.edu # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 - And I can bind as that user (after adding the -W flag to prompt for a password): - # ldapsearch -x -H ldap://genet.ipa.middlebury.edu -D 'uid=ju...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc=edu' -b cn=compat,dc=ipa,dc=middlebury,dc=edu -s sub '(uid=ju...@middlebury.edu)' -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (uid=ju...@middlebury.edu) # requesting: ALL # # ju...@middlebury.edu, users, compat, ipa.middlebury.edu dn: uid=ju...@middlebury.edu,cn=users,cn=compat,dc=ipa,dc=middlebury,dc=edu objectClass: posixAccount objectClass: top cn: juser gidNumber: 435021613 gecos: juser uidNumber: 435021613 homeDirectory: /home/middlebury.edu/juser uid: ju...@middlebury.edu # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 - But the user still cannot SSH in to the client: - $ ssh -l 'MIDD\juser' yakko.ipa.middlebury.edu MIDD\ju...@yakko.ipa.middlebury.edu's password: Permission denied, please try again. MIDD\ju...@yakko.ipa.middlebury.edu's password: Permission denied, please try again. MIDD\ju...@yakko.ipa.middlebury.edu's password: Permission denied (publickey,gssapi-with-mic,password). - The sssd debug_level is set to 10. I've attached sssd_default.log and sssd_nss.log I don't see any request going to sssd. Can you try with ju...@middlebury.edu? Old SSSD is incapable to see MIDD\juser being the same as ju...@middlebury.edu. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] RHEL 5 client?
On Fri, 03 Apr 2015, Guertin, David S. wrote: I don't see any request going to sssd. Can you try with ju...@middlebury.edu? Old SSSD is incapable to see MIDD\juser being the same as ju...@middlebury.edu. When I try: ssh -l 'ju...@middlebury.edu' yakko.ipa.middlebury.edu There is no response for two minutes, followed by "Connection closed". I've attached the resulting sssd_default.log and sssd_nss.log. What slapi-nis and ipa packages are on the IPA master side? This all looks like IPA masters don't have RHEL 7.1 update 1 packages from https://rhn.redhat.com/errata/RHSA-2015-0728.html where exactly this problem with initgroups was fixed. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Proper configuration of service accounts
On Fri, 03 Apr 2015, Dmitri Pal wrote: On 04/03/2015 09:36 AM, Brian Topping wrote: On Apr 3, 2015, at 6:17 AM, Dmitri Pal <mailto:d...@redhat.com>> wrote: On 04/03/2015 01:51 AM, Brian Topping wrote: Great work on 4.1.0! As a CentOS user, I am able to convey the 3.x -> 4.1.0 upgrade went smoothly via the CentOS 7.0 -> 7.1 upgrade on my replicated pair of IPA instances. Question about proper setup of service accounts: I see that the service accounts I set up under "cn=etc, cn=sysaccounts" are still able to log in, but the permission changes have left them unable to read anything. Previously, I hacked the ACLs on the domain root. I would like to believe that's not how it should be done. That said, I was surprised that service accounts are not supported in 4.x UI, so I wonder if service accounts (https://www.redhat.com/archives/freeipa-users/2012-June/msg00011.html) are the wrong way for services like Postfix to be doing LDAP queries. The ACIs changed because we tightened them for the read permissions. I hope you would be able to change them so that your service account works again. Here is the root page of the changes that we implemented. http://www.freeipa.org/page/V4/Permissions_V2 System account is probably the right one for Postfix. It is not in the UI and CLI because other features take precedence. We acknowledge that it needs to be added, we just not have enough time and resources to do it. When we looked at 4.2 we assessed it too and it was on the border line with a good chance of not happening, sorry. Thanks Dmitri. I had known in advance about the ACLs, but couldn't fully appreciate what was going to happen until doing the upgrade. Once it was done, I was kind of surprised that the ACL changes replicated to the 3.x server. As luck would have it, I didn't snapshot both servers at the same time before upgrading either, and eventually, the ACLs managed to work their way back to both the 3.x snapshots (one of them was obviously snapshotted after the other one had been installed with 4.1). I couldn't find upgrade notes with "gotcha"s, this might be a good addition if there are somewhere. It was kind of humorous in all. As for the service feature itself, please don't apologize. I think you guys did a spectacular job with this feature set. What I was concerned about is making sure I am doing things as closely as possible to future patterns to reduce upgrade costs. I don't know if it's possible to document the pattern without committing to the feature, but it might be helpful. The one thing I would like to discover at this point is whether roles and privileges build in the UI can be used by system accounts. I am eager to know that too, please do not hesitate to share your findings. :-) I don't think you can achieve that with existing 'ipa permission-add' command because it limits memberof filter to existing IPA groups. We have an update plugin that updates managed permissions and it could be used as a basis to add more permissions declarative-style but right now it can't be used as it is. Definitely worth filing a ticket and fixing this ASAP. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Question on freeipa-server-trust-ad
On Sat, 04 Apr 2015, Coy Hile wrote: Hi all, What purpose does this package serve? The way I’ve done Kerberos between Active Directory and AD, the trust was always one way (outgoing): the MIT realm is authoritative and AD “shadow accounts” were mapped to ‘real’ principals via the alternateSecurityID attribute. Looking at what freeipa-server-trust-ad installs, it appears the dependencies installed are around letting someone a bidirectional trust (or at least let the AD users be authoritative). If one wants to setup his trust in the way I described, all he really needs to do in MIT land is create krbtgt/AD.REALM@MIT.REALM in the MIT Realm. Is there a ‘supported’ way to do something similar with FreeIPA? Time to break out kadmin.local -x ipa-setup-override-restrictions? Or would that not drop the principal in the right place in the LDAP tree? Let me answer this mail as Simo didn't answer a key part of it and I feel with a growing number of subscribers and people looking at the archives it might bring a lot of misunderstanding. FreeIPA implements cross-forest trust to AD in terms of AD protocols. Part of it is Kerberos cross-realm trust, right, but not only that. In particular, FreeIPA side uses Samba to implement required NetLogon, LSA, and SAMR interfaces required by AD to validate the trust. This causes AD DCs to think that FreeIPA realm is a proper AD forest, not just 'external Kerberos realm'. As result, a proper set of trusted domain objects is created in AD and can be used by FreeIPA to perform lookups of AD users and groups and a proper information about internal FreeIPA realm structure is conveyed to AD DCs, including details of DNS ownership which are crucial to decide what KDCs are responsible in handling specific hosts and subdomains. We are deliberately not supporting external Kerberos trust with Active Directory because we believe this has very little value in an enterprise environment without additional means to deliver such topology details and SID to name and name to SID translation for Kerberos principals on each Windows client. Instead of focusing on a manual maintenance of such mappings on Windows side which would have required us to spend time on implementing software for Windows with obvious limitations due to need to rewrite half of LSA stack on Windows to support all features we want (look at pGINA story and how they failed with it), we chose to concentrate on improving Linux interoperability based on the protocols Microsoft has to support itself to make sure their own Windows clients would work. Right now FreeIPA only supports looking up AD users and groups and is not being able to provide a fully-compliant service so that AD DCs could look up FreeIPA users and groups. This results in Windows machines not being able to resolve SIDs of FreeIPA users and groups to human-friendly names and therefore inability to assign permissions in Windows user interfaces in Security tabs to allow or deny certain access rights to resources on Windows machines. We are working on implementing remaining components so that it will be possible to use FreeIPA users on Windows side too. Even with those components we are not going to implement all features required to present ourselves as Active Directory so no direct join of Windows machines to FreeIPA is planned. Instead, we are continuing to pursue an approach where FreeIPA is seen by AD as another AD forest and trust relationship is used to provide access to resources in both forests. Samba usage in FreeIPA, thus, is limited to being a 'NT4 member server', using LDAP store of FreeIPA to keep users, groups, and trusted domains' accounts. Samba's Active Directory Domain Controller mode is not used but we are working on making sure FreeIPA and Samba AD DC are capable to trust each other as cross-forest trust and, thus, Samba AD DC would be used to enroll Windows machines while Linux machines would be enrolled to FreeIPA. We are at a stage where there is a hope to demonstrate a working solution during SambaXP conference next month and have all the bits and pieces merged upstream Samba. A somewhat detailed overview how FreeIPA trust to AD works is available in the design section of http://www.freeipa.org/page/V4/One-way_trust -- what is described as 'FreeIPA v3.0 and v3.3' is applicable to v4.1 too, we plan to complete the changes by v4.2. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Two way trust vs one way trust and IPA features
On Tue, 07 Apr 2015, Andrey Ptashnik wrote: Hello, I’m wondering if establishing two way trust or one way trust in upcoming 4.2 release somehow is going to affect FreeIPA feature set, like ability to add windows groups to external groups or anything else I may not think of right now? No, it should not affect existing feature set. There will be some tightening of access controls for how administrative tasks would be done to some degree but they already required admin privileges anyway so it is not a change in functionality. Our Windows security team is expressing concerns about two way trust and we are planning to switch to one way when it becomes available. I’m trying to find out what could be affected. Nothing really changes between current use of two-way trust and a future one-way trust in a sense of what is already available to IPA side to look up on AD side. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Freeipa 4 and AD
On Wed, 08 Apr 2015, Aric Wilisch wrote: I’m having issues with getting my RHEL 7 server running Freeipa 4 to join my Windows 2012R2 domain. DNS checks out fine. When I try to establish the join I get the below listed errors popping up. I’ve tried both creating the trust from Freeipa and just this morning I setup the trust on the AD side and tried to use the —trust-secret option. There are no firewalls between them, but they are on different subnets. Any help would be great. This is holding up a project and I’m not able to figure out what’s going on. Thanks in advance. finddcs: Skipping DC 10.32.145.134 with server_type=0xf17c - required 0x0119 You need to establish trust using a PDC of the forest root domain. Your DC is not a PDC (lacks bit 1 in the server type), thus it is not possible to establish cross-forest trust. This is Active Directory requirement. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] How to set the home directory for AD users?
On Thu, 09 Apr 2015, Guertin, David S. wrote: We have a trust relationship set up between our IPA domain and our AD domain. When ad AD user logs in to an IPA client, they are given a home directory of /home//. I would like to change this to /home/. (I'm not interested in automatically creating the home firectory on login, I just want to change the directory name.) The users are not assigned a home directory in AD, so it's up to IPA to set it. In the [nss] section of /etc/sssd/sssd.conf, I have homedir_substring = /home but that doesn't do it. Neither does: fallback_homedir = /home/%u Where can this variable be set? If your clients are RHEL 7.1, remove all of the hacks and use ID Views instead. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/id-views.html ID view 'Default Trust View' will be applied automatically -- on RHEL7.1 clients by SSSD picking it up from IPA master, on legacy clients by their lookups to compat trees. On RHEL6.6 I think SSSD is not capable doing the lookup 'RHEL7.1 way' yet but a rebase is planned to get next update cycle to catch up. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD --> IPA trust --::-- ipa: ERROR: Insufficient access: CIFS server denied your credentials
On Sat, 11 Apr 2015, g.fer.or...@unicyber.co.uk wrote: Guys Anyway of simply skipping the CIFS mount credentials bit? I do not actually need the AD CIFS at this point. What do you mean by that? Establishing trust uses SMB protocols family, it is not using 'CIFS mount' but file system operations are part of SMB protocols family, along with authentication, authorization, domain and trust management. Your 'Admin' user on AD side should be member of either Enteprise Admins, Domain Admins of the forest root domain, or Schema Admins groups. See https://technet.microsoft.com/en-us/library/cc755700%28v=ws.10%29.aspx for details. ipa trust-add --type=ad ad.domain.com --admin Admin --password Active Directory domain administrator's password: ipa: ERROR: Insufficient access: CIFS server denied your credentials --- ot NTLMSSP neg_flags=0x60088205 NTLMSSP_NEGOTIATE_UNICODE NTLMSSP_REQUEST_TARGET NTLMSSP_NEGOTIATE_NTLM NTLMSSP_NEGOTIATE_ALWAYS_SIGN NTLMSSP_NEGOTIATE_NTLM2 NTLMSSP_NEGOTIATE_128 NTLMSSP_NEGOTIATE_KEY_EXCH s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7f31e9911d50 s4_tevent: Destroying timer event 0x7f31e9911d50 "dcerpc_timeout_handler" dcerpc: alter_resp - rpc fault: WERR_ACCESS_DENIED s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f31e99093a0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7f31e99093a0 Failed to bind to uuid 12345778-1234-abcd-ef00-0123456789ab for 12345778-1234-abcd-ef00-012345678...@ad.ad.domain.com[49155] NT_STATUS_LOGON_FAILURE s4_tevent: Destroying timer event 0x7f31e80539d0 "dcerpc_connect_timeout_handler" [Sat Apr 11 06:00:17.408265 2015] [:error] [pid 25074] ipa: INFO: [jsonserver_session] ad...@linux.domain.com: trust_add(u'domain.com', trust_type=u'ad', realm_admin=Admin', realm_passwd=u'', all=False, raw=False, version=u'2.114'): ACIError This is freeipa-server-4.1.4-1.el7.centos.x86_64 Thanks!! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Multi-Master IPA deployment with AD Trusts: Stability and Consistency Expectations?
On Mon, 13 Apr 2015, Traiano Welcome wrote: Hi List The deployment I'm contemplating is as follows: 1. FreeIPA master at a central site,with AD Trust established to the primary DC. 2. Replicas of the FreeIPA master at 4 other sites (with varying WAN latency between central and site),with replication agreements only with to the master at the central site. (So the AD trust is estalished only between the master IPA server and the primary AD domain controller) There is also an existing domain controller at each site that synchs to the primary domain controller at the main site. I'd like AD user access to Linux systems at each site to be stable and consistent as possible, so to rule out the effect of WAN latency and possibly intermittent connectivity (and a host of possibly other unknown factors), I plan to establish an AD trust between the replica at each site and the local AD domain controller. My thinking is that AD user accounts information will then be available to the replica almost as soon as it's available to the AD dc at that site. So ultimately, the consistency of user information should be as good as can be expected from AD's cross wan replication to remote sites, even if the synchronisation between a replica and master is not 100% sin synch at all times (e.g due to WAN latency). My concern is that multiple trusts established this way may lead to replication inconsistency betweend master IPA server and it's replicas,especially in the case where the replica is seeing AD information in different stages of replication. My question: Does IPA cope with this scenario? Is it safe, and will it improve AD authentication performance (at least from the user point of view) to establish trust between each replica and the local domain controller in each given site? This topic was raised already in March on this list so please study archives for more details about site-awareness in SSSD. One thing I must note is that you seem to share a common misunderstanding of how trust to Active Directory is established. There is *no* need to 'establish an AD trust between the replica at each site and the local AD domain controller'. The trust is established once and for whole forest. Information about the trust is replicated to all IPA masters. In order to get them activated to *provide* access to already established trust you need to run 'ipa-adtrust-install' on each IPA master. However, you *don't* need to run 'ipa trust-add' again, and even if you ran it, it would fail because each of your local AD DCs are not a primary domain controllers for your forest root domain. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can an Active Directory domain be the default domain?
On Mon, 13 Apr 2015, David Guertin wrote: In our newly-setup IPA environment, users can log in to RHEL clients with the username @addomain. This works, but I've run into a problem with some RHEL 5 clients that are Apache servers -- the Apache UserDir mappings no longer work. Many of the users have web pages served from the public_html directory in their home directory. With our old NIS configuration, the URL is of the form http://hostname/~username. With the new IPA configuration, these URLs no longer work; the web pages are now found in http://hostname/~username@addomain. I can think of several ways to approach this problem, but my first thought is to have IPA recognize the AD domain as the default domain, so that our users could log in with instead of @addomain, and the existing URLs will work. Is this possible? I was looking at the auth_to_local setting in /etc/krb5.conf, but I couldn't figure out what to do with it. auth_to_local is for a different purpose. It is not possible to change SSSD to use default domain of AD forest root domain on IPA master because you'll break the compat tree and SSSD on IPA clients. Compat tree and extdom plugin are expecting to have normalized user names on IPA master. Additionally, compat tree is expecting normalized names to come from legacy clients, it is the only way we efficiently recognizing these requests to be done against AD users and not doing a search for every misnamed IPA user. Said that, you can set default domain in SSSD configuration on the legacy clients (RHEL 5) as then SSSD will ensure proper fully-qualified name will be sent towards compat tree and non-qualified name can be asked on the client (RHEL 5) side. However, this will only work in case you have a single AD domain in a forest. If you have more than one AD domain, you are out of luck. I'd suggest looking into mod_rewrite configuration to handle @addomain part in Apache configuration. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Sudo rules w/ external users (RHEL7)
On Mon, 13 Apr 2015, Gould, Joshua wrote: I’ve looked at the docs and it looks as if I can specify an external user who can have sudo rights via IPA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/defining-sudorules.html#about-external-sudo The issue being that when I try to add my AD Trust user, it doesn’t allow the @ sign. (ex. gould@test.osuwmc). If I modify the sudo rule to allow all users, I can see that it allows my AD account sudo rights. $ sudo –l User gould@test.osuwmc may run the following commands on this host: (ALL : ALL) ALL How can I configure the rule to allow certain AD users to be able to execute certain sudo rules? Through external users' groups mechanism we use for any other AD users mapping in HBAC and SUDO. These are not local (not defined in IPA but defined on the host) groups and users but rather AD groups and users. ipa group-add --external gould_group_ext ipa group-add-member gould_group_ext --external=gould@test.osuwmc ipa group-add gould_group ipa group-add-member gould_group --groups=gould_group_ext And now make sudo rule that allows users of gould_group to run needed commands. SSSD will pull in all membership information for gould_group, including AD users. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Sudo rules w/ external users (RHEL7)
On Mon, 13 Apr 2015, Gould, Joshua wrote: On 4/13/15, 11:37 AM, "Alexander Bokovoy" wrote: Through external users' groups mechanism we use for any other AD users mapping in HBAC and SUDO. These are not local (not defined in IPA but defined on the host) groups and users but rather AD groups and users. ipa group-add --external gould_group_ext ipa group-add-member gould_group_ext --external=gould@test.osuwmc ipa group-add gould_group ipa group-add-member gould_group --groups=gould_group_ext And now make sudo rule that allows users of gould_group to run needed commands. SSSD will pull in all membership information for gould_group, including AD users. Just curious, but if we don¹t plan on using any IPA native users, could you skip the last two commands and add gould_group_ext to the sudo rule? No. gould_group_ext has no POSIX attributes and thus is not visible to sudo. I¹ve seen this same basic example used for HBAC, but it never was clear to me why the IPA group needed to be added if you¹re only concerned with AD users? Does it need to be added or do the examples include the IPA group because they assume that you¹ll be wanting to use a mix of AD and IPA users for HBAC and sudo? A schema IPA uses for storing group membership requires existence of an object in LDAP. AD users and groups don't exist in IPA LDAP and thus cannot be addressed directly. For doing this we create a real LDAP object which has reference to AD user/group's SID as a string. SSSD knows about this arrangement and properly pulls information from this LDAP object whenever it is encountered as a member of POSIX group. As result, you can see AD user or group as a member of a POSIX group but we need a helper object to allow this magic to work. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Sudo rules w/ external users (RHEL7)
On Tue, 14 Apr 2015, Martin Kosek wrote: On 04/13/2015 05:37 PM, Alexander Bokovoy wrote: On Mon, 13 Apr 2015, Gould, Joshua wrote: I’ve looked at the docs and it looks as if I can specify an external user who can have sudo rights via IPA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/defining-sudorules.html#about-external-sudo The issue being that when I try to add my AD Trust user, it doesn’t allow the @ sign. (ex. gould@test.osuwmc). If I modify the sudo rule to allow all users, I can see that it allows my AD account sudo rights. $ sudo –l User gould@test.osuwmc may run the following commands on this host: (ALL : ALL) ALL How can I configure the rule to allow certain AD users to be able to execute certain sudo rules? Through external users' groups mechanism we use for any other AD users mapping in HBAC and SUDO. These are not local (not defined in IPA but defined on the host) groups and users but rather AD groups and users. ipa group-add --external gould_group_ext ipa group-add-member gould_group_ext --external=gould@test.osuwmc ipa group-add gould_group ipa group-add-member gould_group --groups=gould_group_ext And now make sudo rule that allows users of gould_group to run needed commands. SSSD will pull in all membership information for gould_group, including AD users. Theoretically, adding AD users as *external* users to the SUDO rule should work, given they are stored as a bare string, no? See example of such rule below.. # ipa sudorule-show test --all --raw dn: ipaUniqueID=01405730-e273-11e4-9df6-001a4a104e33,cn=sudorules,cn=sudo,dc=f21 cn: test ipaenabledflag: TRUE hostcategory: all externaluser: foouser ipaUniqueID: 01405730-e273-11e4-9df6-001a4a104e33 memberallowcmd: ipaUniqueID=11281796-e273-11e4-abfe-001a4a104e33,cn=sudocmds,cn=sudo,dc=f21 objectClass: ipasudorule objectClass: ipaassociation The change in FreeIPA would be then only a matter of allowing users with '@' in 'externaluser' attribute You lose validation of the user name here (we do validate that AD user in question exists). And externaluser* options are deprecated. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Synology DSM5 and freeIPA
truggling with is to find the correct >>>>> approach about NFS home dirs. >>>>>>>> The ideal setting would be: >>>>>>>> - home dirs on the NAS >>>>>>>> - IPA manages automount maps >>>>>>>> - home dirs are created automatically at first login >>>>>>>> >>>>>>>> The documentation I could find on these topics includes only >>>>> not-so-recent pages (anything I missed?): >>>>>>>> >>>>>>>> http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>>>>>>> >>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html >>>>>>>> >>>>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories >>>>>>>> >>>>> http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ >>>>>>>> >>>>>>>> Now, I admit I don't have much experience with setting up NFS >>>>> homes, with or without freeIPA, so trying to get this done correctly in the >>>>> context of freeIPA and without clear howtos isn't very easy, but I'm >>>>> willing to get my hands dirty. >>>>>>>> >>>>>>>> The first problem I struggle with is on the correct approach. >>>>>>>> From the documentation above, I understand that there is a bit of a >>>>> chicken-egg problem about the creation of home dirs. >>>>>>>> On the one hand, it would be optimal to have automount maps to load >>>>> only single home dirs on demand, rather than the entire /home tree. >>>>>>>> On the other hand, if the /home tree is not available, then >>>>> creating /home/user1 dir automatically isn't really possible. >>>>>>>> >>>>>>>> Just mounting the whole /home tree would make things easier, but I >>>>> don't have a feeling of when it starts to become a performance issue >>>>> (assuming recent hardware and up to date software). 10 users? 50? 100? 500? >>>>> No idea. >>>>>>>> The realm I'm dealing with at the moment is in the range of 5-10 >>>>> users and probably won't be larger than 50 in the next few years (and if it >>>>> will, it means things are going well, so what the heck ;) >>>>>>>> Also true that, with such few users, I could just create the >>>>> homedirs manually when needed (this is not an organisation where many users >>>>> come and go) and just mount the individually. >>>>>>>> Any tips about this? >>>>>>>> >>>>>>>> Best, Roberto >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Some of these questions are really outside the scope of this list. >>>>>>> You might consider asking them on the NFS list. >>>>>>> >>>>>>> -- >>>>>>> Thank you, >>>>>>> Dmitri Pal >>>>>>> >>>>>>> Sr. Engineering Manager IdM portfolio >>>>>>> Red Hat, Inc. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>>> Go to http://freeipa.org for more info on the project >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thank you, >>>>>> Dmitri Pal >>>>>> >>>>>> Sr. Engineering Manager IdM portfolio >>>>>> Red Hat, Inc. >>>>>> >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go to http://freeipa.org for more info on the project >>>>>> >>>>>> -- >>>>>> Manage your subscription for the Freeipa-users mailing list: >>>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>>>> Go to http://freeipa.org for more info on the project >>>>> >>>>> >>>> >>>> -- >>>> Manage your subscription for the Freeipa-users mailing list: >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> Go to http://freeipa.org for more info on the project >>>> >>> >>> >>> >>> >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> -- >>> Manage your subscription for the Freeipa-users mailing list: >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> Go to http://freeipa.org for more info on the project >>> >> >> > > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: AD DC was unable to reach any IPA domain controller --- AD domain controller complains about communication sequence.
On Tue, 14 Apr 2015, g.fer.or...@unicyber.co.uk wrote: Hi Dealing with AD --> Cert Trust I am reaching the following step: ipa trust-add ad.company.com --admin --password Active Directory domain administrator's password: ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue Reaching this far I do not know what the issue is .. Nevertheless and before start playing around with the DNS further more The issue is what reported above -- at request of IPA DC to validate the trust, AD DC tried to resolve IPA DC via SRV records and then tried to contact its Samba instance on its own to complete validation of the trust. Either step might fail, after which AD DC would report back to IPA DC that it was unable to reach it. This diagnostics wasn't added for nothing, you need to trust it. :) if I run the following it seems to successfully establish the trust by the IPA side of the business # ipa trust-add --type=ad "ad_domain" --trust-secret So this part seems find by the look of it.. It works because it does not communicate with AD DCs here, only with IPA's Samba instance. I also had to manually add the AD host and the remote CIFS resource but I am getting instead: ipa trust-fetch-domains corp.hootsuitemedia.com ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example This doesn't work because AD DC did not complete the trust validation and cannot trust IPA Kerberos tickets, thus refusing operation. Unfortunately, reporting in SMB protocol is less than perfect so we only are able to get guesses at what has happened. In any case, running trust-fetch-domains makes no sense until you complete validation. And to complete validation you really need to fix issues with either DNS or firewall so that AD DCs are capable to reach proper IPA DCs. And all IPA DCs should be initialized with ipa-adtrust-install currently. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Freeipa4 - AD SSH logins
On Wed, 15 Apr 2015, Aric Wilisch wrote: Today I managed to finally get a trust established between my AD Domain and my FreeIPA 4 environment. However I’m noticing a couple issues and hope someone might be able to give me some help. First when the user logs in it creates their home directory in /home/fioptics/ rather than /home/. I read that you had to put subdomain_homedir= /home in /etc/sssd/sssd.conf but that didn’t seem to fix it. Also the FreeIPA environment is set to use /bin/bash as the shell, however everyone from AD is logging in and using /bin/sh. I’m hoping if I can get these issues sorted out the other issues I”m seeing with go as well, but if they don’t I can address those at that time. These issues are addressed with IDViews functionality in FreeIPA 4.1. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/id-views.html I have a 'sneak peak' videos of how this feature works: http://talks.vda.li/video/freeipa-idviews-override-shell-and-homedir.webm http://talks.vda.li/video/freeipa-idviews-override-public-ssh-key.webm These are draft sequences, no sound or subtitles so you need to read documentation too :) -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Freeipa4 - AD SSH logins
On Wed, 15 Apr 2015, Aric Wilisch wrote: So I would have to setup an ID View Override for every user in AD that needs to login to to a FreeIPA host? I guess I’m having trouble understanding why it wouldn’t just use the defaults set into FreeIPA? The Default home directory is set to /home and the default shell is set to /bin/bash. Because you have options on how you would set identity mapping for AD users, there is no single way to apply these defaults. - You can have POSIX attributes defined in Active Directory. - this means you can use any existing tool on Windows to set POSIX attributes for each user manually or with automation tools - FreeIPA will notice the attributes and configure ID ranges of the trusted domains to pick up POSIX attributes from Active Directory - SSSD will use ID range type to pull POSIX attributes from Active Directory - You can have POSIX attributes generated automatically for AD users by FreeIPA - this means some safe defaults will be applied by SSSD running on IPA master, these are based on sssd.conf options for subdomain_* - these defaults will affect AD users' only UID/GID information for client-side SSSD <1.12 because old SSSD doesn't know how to pick up the rest of attributes - for SSSD >= 1.12 the defaults from IPA master will be honored by IPA clients automatically - in both cases ID View 'Default Trust View' can be used to configure POSIX attributes for AD users explicitly. There are no templates though. If templating is needed in ID Views, a ticket could be filed. Perhaps it is a good idea but it will take time to implement in FreeIPA (management), SSSD and slapi-nis (application of defaults). This is a lot of work to go to unless there’s a way to set it globally for the entire domain. Also noticing sudo doesn’t work for those users even though I have the ad_admins group added to the sudo group I created. Open a separate thread and provide SSSD logs, our debugging capabilities are distinguishable from magic and thus require help from you. ;) -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: AD DC was unable to reach any IPA domain controller --- AD domain controller complains about communication sequence.
ntact logon servers (DCs) of IPA". If try to mount any of the remote AD shares into the IPA server manually , it does perfectly well with the above user details.(this is without kerberos so -k) If you mount something on IPA server, it means connection goes from IPA server to AD DC, not the other way around. You need to make sure the opposite direction (connection initiated by AD DC towards IPA server) would work. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Critique
On Fri, 17 Apr 2015, Andrew Holway wrote: In an obviously blatant promotion exercise and attempt to build page rank Please could I have some critique on this article? http://otternetworks.de/tech/freeipa-technical-brief/ Your feedback would be really appreciated Thanks for the nice article showing how to enable OpenVPN with two-factor authentication. My notes: - Title is misleading as article is about setting up OpenVPN with two-factor auth, not really about FreeIPA itself - You mention "Using a completely standard client OpenVPN configuration with only one addition “auth-user-pass” to prompt for a password we are able to use OpenVPN to log into a network using password+OTP." However, there is no config example that shows it. I would add that, along the lines of using PAM plugin. - It would probably be good to mention that by using PAM authentication plugin you also get HBAC rules from FreeIPA to fine tune which users can actually use this VPN concentrator. As it is, any user from your system would be able to use VPN but most probably you'd want to limit them by group membership and it is better to achieve by using HBAC rules. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] LDAP bind failing on new IPA setup
On Fri, 17 Apr 2015, Gould, Joshua wrote: We setup our new IPA server (RHEL7) with a trust against our AD domain. The trust and ID range look right in IPA [root sssd]# ipa trust-show Realm name: example.com Realm name: EXAMPLE.COM Domain NetBIOS name: EXAMPLE Domain Security Identifier: S-1-5-21- Trust direction: Two-way trust Trust type: Active Directory domain [root sssd]# ipa idrange-find --all 2 ranges matched dn: cn=EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=examle,dc=com Range name: EXAMPLE.COM_id_range First Posix ID of the range: 200 Number of IDs in the range: 90 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21- Range type: Active Directory domain range iparangetyperaw: ipa-ad-trust objectclass: ipatrustedaddomainrange, ipaIDrange dn: cn=UNIX.EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=example,dc=com Range name: UNIX.EXAMPLE.COM_id_range First Posix ID of the range: 36960 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range iparangetyperaw: ipa-local objectclass: top, ipaIDrange, ipaDomainIDRange Number of entries returned 2 Either you obfuscated too much or your setup makes little sense as IPA local domain ID range is for unix.example.com while your realm is EXAMPLE.COM and AD realm is EXAMPLE.COM. This is not going to work -- IPA and AD has to have different realms. [root sssd]# I see that the bind fails but I’m not sure why. Here are the errors. Could someone point me in the right direction please? A single line you need to look at is this: (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC policy rejects request)] KDC policy rejects request is Kerberos way of saying "My realm doesn't trust your realm, go away". In order to know what exactly is wrong, do following (it is all written in the troubleshooting section of the trust documentation on FreeIPA wiki): 1. add 'log level = 100' to [global] section of /usr/share/ipa/smb.conf.empty 2. Without restarting anything, re-establish trust with 'ipa trust-add ...'. 3. Look into /var/log/http/error_log to see a response for something like this: s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5ccc084a40 netr_LogonControl2Ex: struct netr_LogonControl2Ex out: struct netr_LogonControl2Ex query: * query: union netr_CONTROL_QUERY_INFORMATION(case 2) info2: * info2: struct netr_NETLOGON_INFO_2 flags: 0x00b0 (176) 0: NETLOGON_REPLICATION_NEEDED 0: NETLOGON_REPLICATION_IN_PROGRESS 0: NETLOGON_FULL_SYNC_REPLICATION 0: NETLOGON_REDO_NEEDED 1: NETLOGON_HAS_IP 1: NETLOGON_HAS_TIMESERV 0: NETLOGON_DNS_UPDATE_FAILURE 1: NETLOGON_VERIFY_STATUS_RETURNED pdc_connection_status: WERR_OK trusted_dc_name : * trusted_dc_name : '\\rh7-1.ipacloud7.test' tc_connection_status : WERR_OK result : WERR_OK If instead of WERR_OK in pdc_connection_status you have something else, that is telling an error. Show us the output like above. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC and SUDO rules for legacy clients
On Mon, 20 Apr 2015, Srdjan Dutina wrote: Hi, Testing FreeIPA 4.1.0 (Centos 7 (1503)) with AD 2012 R2 trust. For Centos 5.11 Client (SSSD 1.5.1), will HBAC and SUDO rules function? If yes, does this apply AD users also? SSSD 1.5.1 does not have SUDO support. HBAC support in 1.5.1 will mot likely not work with compat tree that is required for legacy clients to support AD users. I don't think this was even tested. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC and SUDO rules for legacy clients
On Mon, 20 Apr 2015, Srdjan Dutina wrote: Thank for quick answer! If I disable HBAC rule, I can still login to Centos 5 client using IPA user, but not using AD user. Is there a workaround? I need "allow_all" disabled because of newer IPA clients. There is no workaround so far. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC and SUDO rules for legacy clients
On Mon, 20 Apr 2015, Srdjan Dutina wrote: Just found in http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf the next sentence: "If you have HBAC's allow_all rule disabled, you will need to allow system-auth service on the FreeIPA master, so that authentication of the AD users can be performed." Is this true for FreeIPA 4.1.0 also and how could I do this? Either you are reading it wrong or I don't get where you want to apply HBAC rules because this is for IPA masters, not legacy clients per se. Yes, you nede to create HBAC service named 'system-auth' and grant access to it to AD users on IPA masters, but all it will allow you is to authenticate AD users via compat tree. If your RHEL5 SSSD clients attempt to run own HBAC rule checks, AD users cannot be checked by those rules. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa: ERROR: non-public: TypeError -- ipa trust-add crash
On Tue, 21 Apr 2015, g.fer.or...@unicyber.co.uk wrote: Hi This is for freeipa-server-4.1.4-1.el7.centos.x86_64 When Running: ipa trust-add --type=ad ad.domain.com --admin --password ipa: ERROR: an internal error has occurred Some more info at : /var/log/httpd/error_log num_setup=2, max_setup=0, param_total=0, this_param=0, max_param=0, data_total=116, this_data=116, max_data=4280, param_offset=84, param_pad=2, param_disp=0, data_offset=84, data_pad=0, data_disp=0 smb_signing_md5: sequence number 14 smb_signing_sign_pdu: sent SMB signature of [] FD A6 9F 6B 2F 72 8D 4F ...k/r.O smb_signing_md5: sequence number 15 smb_signing_check_pdu: seq 15: got good SMB signature of [] B3 5C 71 C9 1F E4 21 35 .q...!5 rpc reply data: [] 00 00 02 00 08 00 00 00 32 00 34 00 04 00 02 00 2.4. [0010] 32 00 34 00 08 00 02 00 00 00 00 00 03 00 00 00 2.4. [0020] 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0030] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0040] 00 00 00 00 1A 00 00 00 00 00 00 00 19 00 00 00 [00C0] 6D 00 00 00 00 00 00 00 m... [Mon Apr 20 22:59:48.849462 2015] [:error] [pid 32475] ipa: ERROR: non-public: TypeError: default/librpc/gen_ndr/py_lsa.c:9436: Expected type 'security.dom_sid' for 'py_dom_sid' of type 'NoneType' [Mon Apr 20 22:59:48.849484 2015] [:error] [pid 32475] Traceback (most recent call last): [Mon Apr 20 22:59:48.849486 2015] [:error] [pid 32475] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 349, in wsgi_execute [Mon Apr 20 22:59:48.849489 2015] [:error] [pid 32475] result = self.Command[name](*args, **options) [Mon Apr 20 22:59:48.849491 2015] [:error] [pid 32475] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ [Mon Apr 20 22:59:48.849492 2015] [:error] [pid 32475] ret = self.run(*args, **options) [Mon Apr 20 22:59:48.849494 2015] [:error] [pid 32475] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run [Mon Apr 20 22:59:48.849496 2015] [:error] [pid 32475] return self.execute(*args, **options) [Mon Apr 20 22:59:48.849498 2015] [:error] [pid 32475] File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line 474, in execute [Mon Apr 20 22:59:48.849500 2015] [:error] [pid 32475] result = self.execute_ad(full_join, *keys, **options) [Mon Apr 20 22:59:48.849502 2015] [:error] [pid 32475] File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line 709, in execute_ad [Mon Apr 20 22:59:48.849504 2015] [:error] [pid 32475] self.realm_passwd [Mon Apr 20 22:59:48.849506 2015] [:error] [pid 32475] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1222, in join_ad_full_credentials [Mon Apr 20 22:59:48.849507 2015] [:error] [pid 32475] self.remote_domain.establish_trust(self.local_domain, trustdom_pass) [Mon Apr 20 22:59:48.849509 2015] [:error] [pid 32475] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 963, in establish_trust [Mon Apr 20 22:59:48.849511 2015] [:error] [pid 32475] self._pipe.DeleteTrustedDomain(self._policy_handle, res.info_ex.sid) [Mon Apr 20 22:59:48.849513 2015] [:error] [pid 32475] TypeError: default/librpc/gen_ndr/py_lsa.c:9436: Expected type 'security.dom_sid' for 'py_dom_sid' of type 'NoneType' [Mon Apr 20 22:59:48.849782 2015] [:error] [pid 32475] ipa: INFO: [jsonserver_kerb] ad...@ldap.domain.com: trust_add(u'ad.domain.com', trust_type=u'ad', realm_admin=u'ad_user', realm_passwd=u'', all=False, raw=False, version=u'2.114'): TypeError Have you seen any of this before? No. Can you file a bug or ticket and attach full httpd's error_log there? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] group membership listing?
On Tue, 21 Apr 2015, Rob Crittenden wrote: Janelle wrote: Hello - and happy day before Earth Day, Perhaps this is an easy one and related to replication, BUT: $ id some-user-name If I run that on every IPA master, should the listing not be identical? In other words, the listing of the uid, gid and groups, should show up in exactly the same order? uid=12345(some-user) gid=101(agroup) groups=101(agroup), 102(another), 103(another2) What if one replica listed it as: uid=12345(some-user) gid=101(agroup) groups=101(agroup), 103(another2), 102(another) But all the others listed as the first line? Is that indication of a problem? It may be related to the fact that LDAP doesn't guarantee order and no sorting is done. It is probably not a big deal as long as all the data is there. Not even LDAP but POSIX in general does not give you an ordered guarantee for groups you are member of. There is a primary group always and the rest of groups are 'supplementary', without any ordering. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problems with users from AD trusted domain after update to IPA 4.1
On Wed, 22 Apr 2015, Alexander Frolushkin wrote: Hello. Not sure it happened after update, but now we are on 4.1 and on some servers we have only AD groups if it is primary for user, and have no IPA groups with AD external group in members. Fro example, on the IPA server we have # id afrolush...@ad.com uid=236658172(afrolush...@ad.com) gid=236658172(afrolush...@ad.com) groups=236658172(afrolush...@ad.com),236658193(sib-dwh-sa-adm...@ad.com),810800020(sib-dwh-sa-admins),236667642(rhidm-sa-adm...@ad.com)<mailto:afrolush...@ad.com),236658193(sib-dwh-sa-adm...@ad.com),810800020(sib-dwh-sa-admins),236667642(rhidm-sa-adm...@ad.com)> here group 236658193(sib-dwh-sa-adm...@ad.com<mailto:sib-dwh-sa-adm...@ad.com>) have a IPA group 810800020(sib-dwh-sa-admins), and it is not primary for user. Group, primary for this user - 236667642(rhidm-sa-adm...@ad.com<mailto:rhidm-sa-adm...@ad.com>) also have IPA group, but it is not displayed in id command. On some other servers (IPA clients) it displays ONLY AD groups: # id afrolush...@megafon.ru uid=236658172(afrolush...@ad.com) gid=236658172(afrolush...@ad.com) groups=236658172(afrolush...@ad.com),236667642(rhidm-sa-adm...@ad.com),236658193(sib-dwh-sa-adm...@ad.com)<mailto:afrolush...@ad.com),236667642(rhidm-sa-adm...@ad.com),236658193(sib-dwh-sa-adm...@ad.com)> This is a big problem for us, because on that servers we cannot use HBAC & sudo, also we don't think primary AD group is a exception and cannot be used in IPA authorization. If it is a big problem, make sure you are gathering all the logs and deployment information first to pin point what exactly you are running. See https://fedorahosted.org/sssd/wiki/Troubleshooting for general SSSD troubleshooting. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] kadmin.local to manage FreeIPA Kerberos
On Thu, 23 Apr 2015, Shaik M wrote: Hi, We have recently deployed FreeIPA for our Hadoop environment. Recently, Ambari community released 2.0, where this version supports MIT kerberos. Which means Ambri create the all service principals using with "kadmin.local". As I know, "kadmin.local" wont work for FreeIPA kerberos to create the principals. :( Please let me know, is there any alternative ways to create the principals using with "kadmin.local",. It will great helpful for us if can do with "kadmin.local", or-else we have to move back to MIT Kerberos. No, at this time it is not possible to use. I've looked at the Ambari code and it shouldn't be hard to implement FreeIPA-specific KerberosOperationHandler that does proper thing by calling out IPA tools. Part of problem with MITKerberosOperationHandler.java is that you have no way to pass any arguments and options to kadmin/kadmin.local at all, so even to make it working will go with patching that code. At this point it is easier to rewrite it to use 'ipa' and ipa-getkeytab utilities altogether because the code is trivial. https://github.com/apache/ambari/blob/ed231beaddaf6347d4defb2fb26d75849c0cafc9/ambari-server/src/main/java/org/apache/ambari/server/serveraction/kerberos/MITKerberosOperationHandler.java -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Web UI: Migrated Admins missing action buttons
- Original Message - > Hi Rob and Dimitri > > Migrating via Replica is the obvious way that I would have gone, had the > FreeIPA /RedHat documentation not suggested the replicas must have the same > version. > > I think the link that put me off from replicating was: > > http://www.freeipa.org/docs/1.2/Installation_Deployment_Guide/en-US/html/sect-Installation_and_Deployment_Guide-Setting_up_Multi_Master_Replication-Creating_the_Replica_Information_File.html > > Looking at the link more closely I now see this applies to version > 1.2 ., but from the page itself that was not obvious. it would be great > if the version to which the IPA documentation applies was more obvious > I am sure I am not the only user who enters the documentation via a search > engine. We really need to remove this version 1.x documentation, it is giving too much confusion. Use documentation at the Red Hat Customer Portal: - versions 3.3 and onwards: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html - version 3.0: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/index.html We have all proper links gathered at http://www.freeipa.org/page/Documentation, it has these links and even more, including HOWTOs for integration with other software. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] FYI: Fedora 22 and trusts
Hi, if you are playing with Fedora 22 beta, your experience with FreeIPA may be rough. When installing freeipa-server-trust-ad make sure to also install samba-common-tools package. Samba packaging was split to allow samba-common to be an architecture-independent package but samba package didn't get dependency to samba-common-tools subpackage which contains /usr/bin/net utility. This utility is used by FreeIPA when you run ipa-adtrust-install. I've submitted update which fixes this issue [1] but until it reaches stable updates of Fedora 22, simply install samba-common-tools in addition to freeipa-server-trust-ad. As with any pre-release software, it is recommended to always run up-to-date system as bugs get fixed almost every day before release. [1] https://admin.fedoraproject.org/updates/samba-4.2.1-5.fc22 -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA 4.1.4 and Windows Groups
On Mon, 27 Apr 2015, Zach McNeilly wrote: Hi all, First I'd like to say thank you for the fantastic product. We've been using FreeIPA since v 1 and it's been fantastic. Recently we've hit a slight snag, however. We used this document (https://www.freeipa.org/page/Windows_authentication_against_FreeIPA) to setup Windows to use FreeIPA for it's back end authentication. This works really well and we are really happy with it. You know that it is not a supported configuration, right? To integrate a CIFS server with FreeIPA we ran 'ipa-adtrust-install' on our FreeIPA servers, this added several attributes to every user as expected. However, now when users try to log on to a Windows machine with their FreeIPA credentials they can log on but they are no longer in any Windows groups (Administrators or Remote Desktop Users in this case). This was working before running ipa-adtrust-install. If you remove the following attributes from the user Windows works again but samba no longer does: objectclass=ipantuserattrs ipantsecurityidentifier= I've been banging my head against the wall on this for a while, and can't seem to get everything to mesh. Can anyone make any recommendations? I don't think we can do anything here. Windows takes list of SIDs from Kerberos ticket's MS-PAC which is filled by IPA KDC. The format of MS-PAC includes group list in form of RIDs, i.e. relative identifiers, relative to the domain SID. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeIPA and AD in multi-homed environment
On Tue, 28 Apr 2015, Арсений Черняков wrote: - Hi all. I've got a rather big domain environment with 10 distributed locations, and I'm considering using FreeIPA as an id manager for linux users and servers, alongside with existing AD, using trusts. In every location, there are 2 DCs for windows environment, and I'm thinking about deployment of 2 freeIPA servers for each location, with replicas. This document states that I can't use more than 20 servers per IPA domain: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/Setting_up_IPA_Replicas.html#replica-topologies - "No more than 20 servers and replicas should be involved in a single Identity Management domain." - How strict is this restriction? Is there any way I can deploy freeIPA in this situation, assuming that number of locations would increace over time? Is there any other limitations to integrate freeIPA in AD? The limitations described above are for supported configurations deployed on Red Hat Enterprise Linux. If you want a larger configuration to be supported, you need to contact your Red Hat representatives and work out with them exact support statement. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeIPA and AD in multi-homed environment
On Tue, 28 Apr 2015, Арсений Черняков wrote: Thank you for quick response. So, did I got it right, that this limitation is affecting only RedHat support agreement, and not the technical side of configuration? We're considering the CentOS 7 deployment, and we don't have Red Hat support agreement. Technically 389-ds can address up to 65535 replicas but this says nothing about actual performance which is always a function of your workload, environment, and a number of other factors. If you hit any issues, without support contract they would be handled by a community -- where we all are -- and may involve longer time. I hope it is clear as people involved are giving out their volunteering effort. Maybe it's a stupid question, but since we don't have support agreement, can I still ask questions in RedHat mailing list? (I haven't found any forums/KBs/mailing lists dedicated solely to freeIPA and CentOS). This mailing list is part of FreeIPA community, we see here a lot of questions from different parties using different distributions. It is hosted by Red Hat but not really tied to Red Hat. Still, if you have concerns on getting your whole infrastructure depending on free software solutions, there are solution providers that would be happy to help you in deploying and supporting them. Just don't expect their contract obligations necessarily extend to the community mailing list. :) -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA and sambaPwdLastSet
On Tue, 28 Apr 2015, Dmitri Pal wrote:
On 04/28/2015 12:17 PM, Christopher Lamb wrote:
Hi All
I wish to pick your brains on the attribute sambaPwdLastSet
We have a newly setup FreeIPA 4.1.0, with users and groups migrated from an
old 3.0.0 instance.
We are also running Samba to share files to Windows and OSX users. This
means that all the FreeIPA user accounts have the attribute
sambaPwdLastSet.
If this has the value 0, our users cannot map Samba shares, so we need to
make sure the value is a positive integer.
In an attempt to do this, I modified user.py, adding the attribute to the
takes_params for the class user as follows:
class user(LDAPObject):
. . .
takes_params = (
. . .
Int('sambapwdlastset?',
label=_('sambaPwdLastSet'),
doc=_('Date as an integer when the samba password was last set'
),
default=1,
autofill=True,
),
. . .
This works fine if I create a user via the CLI.
However if I create a user via the Web UI, or use the Web UI to reset a
user's password, then the attribute sambaPwdLastSet is set to zero.
So what scripts do I need to change to make sure the Web UI sets
sambaPwdLast Set to a positive value? (I don't want to run ldapmodify
scripts, or have to use Apache Directory Studio to hack the db..)
Or is there an altogether better approach to handling this field?
Thanks
Chris
May be you should consider managed entry plugin and make this
attribute be updated at the same time the standard password expiration
attribute is updated?
Dmitri, it is already updated -- we set it to 0 when admin changes
user's password.
I've wrote an answer to Chris but forgot to CC: the list. I'll re-send
my answer.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA and sambaPwdLastSet
Resending it to the right list. :) Not my evening.
On Tue, 28 Apr 2015, Alexander Bokovoy wrote:
On Tue, 28 Apr 2015, Christopher Lamb wrote:
Hi All
I wish to pick your brains on the attribute sambaPwdLastSet
We have a newly setup FreeIPA 4.1.0, with users and groups migrated from an
old 3.0.0 instance.
We are also running Samba to share files to Windows and OSX users. This
means that all the FreeIPA user accounts have the attribute
sambaPwdLastSet.
If this has the value 0, our users cannot map Samba shares, so we need to
make sure the value is a positive integer.
In an attempt to do this, I modified user.py, adding the attribute to the
takes_params for the class user as follows:
class user(LDAPObject):
. . .
takes_params = (
. . .
Int('sambapwdlastset?',
label=_('sambaPwdLastSet'),
doc=_('Date as an integer when the samba password was last set'
),
default=1,
autofill=True,
),
. . .
This works fine if I create a user via the CLI.
However if I create a user via the Web UI, or use the Web UI to reset a
user's password, then the attribute sambaPwdLastSet is set to zero.
So what scripts do I need to change to make sure the Web UI sets
sambaPwdLast Set to a positive value? (I don't want to run ldapmodify
scripts, or have to use Apache Directory Studio to hack the db..)
Or is there an altogether better approach to handling this field?
Yes, there is.
Given that you are running FreeIPA 4.1, you now can use SSSD as your
libwbclient provider to be able to run Samba on IPA client against IPA
database. There will be no dependency on sambaPwdLastSet anymore.
See
http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA
This approach requires Fedora 21 or RHEL 7.1 / CentOS 7.1 on the IPA
client. It does not work though with non-Kerberos (NTLM) logins.
However, if you insist on using sambaPwdLastSet attribute, then user
password change rule is applying:
- if admin changes user password, sambaPwdLastSet is cleared to 0 to
force users to change their passwords also via Samba
If user changes the password him/herself, sambaPwdLastSet is set to the
current time (i.e. not 0).
This really goes into enforcing privacy of user passwords -- if admins
change user passwords, the password is not really secret anymore and
cannot be considered secure, so it is only used once.
See also https://www.freeipa.org/page/Self-Service_Password_Reset and
https://www.freeipa.org/page/New_Passwords_Expired
--
/ Alexander Bokovoy
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Master level IPA server
On Wed, 29 Apr 2015, Aric Wilisch wrote: Is it possible to setup a Master level FreeIPA domain, then have 3 sub level domains use it for authentication? So master server at say ipa.domain.com <http://ipa.domain.com/>, then have a secondary zone that is ipa2.sub1.domain.com <http://ipa2.sub1.domain.com/>. This is possible. As long as DNS domains of IPA do not overlap with DNS domains of Active Directory deployment, or any other Kerberos realm, things should work. We have 3 different environments that need to stay separated. We were going to have them all authenticate to an Active Directory domain but getting that setup is turning into a real issue. So if possible I would like to have a master level IPA server, then three sub level IPA servers that authenticate against it, then have our Windows Terminal Servers authenticate against it as well if possible. You cannot login to Windows machines by authenticating against IPA right now, this is not supported. You can establish cross-forest trust between IPA realm and Active Directory and then login to IPA machines with Active Directory credentials. If this is not what you want, IPA is not yet supporting your case. There isn't enough details to see what is your issue, though. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] [WARNING] Trusts are broken in Fedora 22
Hi, If you are eager to try Fedora 22 beta and overall try FreeIPA in Fedora 22, be aware that trusts to Active Directory are currently broken due to Samba 4.2.1 update in Fedora 22. I've pushed build [1] of Samba today that at least allows Samba processes to start properly but establishing trust will fail due to changes in Samba client libraries. I'm investigating the reason for the issues and hope to get them fixed before Fedora 22 final freeze comes. [1] https://admin.fedoraproject.org/updates/samba-4.2.1-7.fc22 -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] 2fa with trusted AD users
- Original Message - > On Fri, 2015-05-01 at 13:03 +, Andy Thompson wrote: > > Is this possible or do they have to be local IPA accounts? Looking > > at options for setting up freeradius with IPA on the backend and > > utilizing OTP, I've got a test case setup and working for local > > accounts but a lot of our users are trusted accounts. > > > > > From what I can tell it is not possible currently but I saw a > > > reference along the line somewhere about external users. Can't > > > really find much info otherwise. > > It is not currently possible. However, I believe Alexander had some > ideas related to this. I've CC'd him. Not supported right now. We haven't started working on it but most likely 2FA support for AD users will come as part of ID Views feature. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Samba4 & Freeipa integration question
- Original Message - > I am using Samba4 as a DC to authenticate windows hosts and would like to use > the same user accounts on the Samba4 DC for authentication on my linux > servers as well. Is it possible to perform this type setup using Samba4 and > Freeipa together? Please provide any excellent guides for this setup too > pls. Thank you in advance! This is not possible right now. Samba 4 AD DC is missing cross-forest trust support which is required for interoperability with FreeIPA. There is ongoing work on implemented needed features in Samba and current set of patches to be merged upstream measured in several hundreds commits. We plan to target Samba 4.3 timeframe. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Cross Realm Authentication between two FreeIPA Servers
- Original Message - > Hi, > can you please let me know, how to setup Cross Realm Authentication between > two FreeIPA Servers? Not supported yet. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Cross Realm Authentication between two FreeIPA Servers
- Original Message - > Do we have any plans to implement in future? Yes, once we get everything ready for fully working AD trusts support (i.e. IPA users being able to login to Windows machines). The reason for that is because we will be re-using the same infrastructure in both cases so the code will largely be the same to drive both use cases. This is very important because then we don't need to update SSSD on the machines where current AD trust feature is already supported -- they will be able to operate with IPA-IPA trust the instant moment it is established. Actual process of setting up IPA-IPA trust will be a bit different, of course, as we have better ways to set the trust up in this case. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Credentials constantly revoked for admin user
On Mon, 04 May 2015, Andrew Morone wrote: I'm having this issue. I discovered when I would randomly get locked out of the admin account with the usual: kinit: Clients credentials have been revoked while getting initial credentials The scenario would go as follows: Sometimes I would try to issue "kinit admin", with the correct credentials only to be met with the above results. Other times it would work fine, only to fail when running an 'ipa' command. Anyway, I discovered a bunch of failed auth entries for admin in the logs, coming from clients. This would be mixed with successful logins from the same machine. So what it looks like is happening is that these failed logins would lock me out, sometimes in the middle of a session. Just waiting 60 seconds for the lock out to time out would allow me to continue my work. Has anyone seen this issue before? I'm using ipa server 3.0 on a CentOS 6.6 server. Are you using admin credentials as a bind DN from some application? Or some application which authenticates against LDAP is DoSed by someone. In any case you would need to look at /var/log/dirsrv/slapd-/access and /var/log/krb5kdc.log. Both logs have enough information to identify from which hosts these authentication attempts come and narrow down exploration of what happens on those hosts. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa-samba integration and windows clients
On Wed, 06 May 2015, box 31978 wrote: Hello everyone, These days I'm testing integration between FreeIPA4 and Samba4 at file sharing level. Everything seems to work fine except share access from a standalone Windows client. This is the setup (everything is up-to-date): - ipa-server: CentOS 7.1, ipa-server 4.1, ipa-server-trust-ad plugin - file-server: CentOS 7.1, ipa-client 4.1, samba 4.1 (sharing home dirs, not a DC) - win-client: Windows 7 Home Premium Config is done following the FreeIPA's Samba integration guide, and testing with samba-client from ipa-server (or any other ipa-joined machine) to file-server using kerberos after calling kinit is successful (file manipulation included). Attempts to connect to the same share from win-client ends up with a log in error. Analyzing logs: Samba can't find the user because it can't find any DC, and that's because Samba can't resolve workgroup name (note that's not a question of SSO: win-client asks to type username and password). It seems that maybe Samba is not handling new kerberos ticket requests. If Windows client is not a part of the domain, there is no SSO and no Kerberos. Windows client will attempt using NTLMSSP authentication. By now, my questions are: - Can this setup work or it is absolutely necessary that any Windows client expecting to access Samba shares have to be already joined to a trusted domain? Right now -- yes. You are saying you've following "FreeIPA's Samba integration guide" which I assume is http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA, which only works for Kerberos authentication because NTLMSSP is not supported by the SSSD. - If this setup can't be done, I'll go for an LDAP config in file-server against ipa-server, but then, can I maintain the file-server joined with ipa-client? Will it work? Not really. The story is more complex than it seems and right now there is no ready-made solution for out-of-domain Windows clients. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa-samba integration and windows clients
On Thu, 07 May 2015, box 31978 wrote: Hello Alexander, Thank you very much for your answers! If Windows client is not a part of the domain, there is no SSO and no Kerberos. Windows client will attempt using NTLMSSP authentication. ... Right now -- yes. You are saying you've following "FreeIPA's Samba integration guide" which I assume is http://www.freeipa.org/page/Howto/Integrating_a_Samba_File_Server_With_IPA , which only works for Kerberos authentication because NTLMSSP is not supported by the SSSD. Yes, your assumption is absolutely exact ;-) That's clear now, my thoughts went on this direction too: anyone is handling a new kerberos ticket request because of authentication type. Not really. The story is more complex than it seems and right now there is no ready-made solution for out-of-domain Windows clients. Ok, I understand. Then, I'd go for an LDAP approach pointing Samba to IPA's directory (this works fine on Samba3 and 389-DS), but I'm not sure about the configuration. Can file-server's SSSD have Kerberos auth (result of ipa-client-install) and LDAP auth (added settings in sssd.conf) at the same time for the same domain? Will it work together or will I've to choose on of the two? SSSD can but you need Samba to be aware of these things because Samba needs way more than just passwords. FreeIPA uses different LDAP schema for the additional attributes compared to what standard Samba PASSDB module for LDAP expects so if you enable that one in smb.conf, you'll get nothing. As Christoph pointed in the another email, you may try to enable older Samba-compatible scheme but that wouldn't play well with IPA's support for SIDs (including on SSSD side) as we are using different attributes and you'll be forced to maintain certain aspects manually. There is hope to get NTLMSSP support implemented but not soon, we have bits in place but there is still work to be done. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Antwort: Re: more replication fun
On Thu, 07 May 2015, Christoph Kaminski wrote: I am curious however. I have been running OpenLDAP configs with 20 or more servers in replication for over 5 years. In all that time, I think I have had replication issues 5 times. In the 6 months of working with FreeIPA, replication issues are constant. From reading the threads, I am not the only one in this predicament. Is there any history on why replication is so problematic in FreeIPA? same here... OpenLDAP no problems, since we use IPA we have ever replikation issues I think the replikation design is the problem. All IPA's are master. I think it would be more stable if there would be 1 Master and all replicas are read only. Replicas cannot be read only right now because this would mean Kerberos would be broken as every issued ticket means modification of the principal's LDAP entry to record account-related information for the successful and unsuccessful authentication. This is important to synchronize with other replicas because it also reflects lockout of accounts. You haven't experienced it with OpenLDAP-based LDAP clusters because most likely you did simply not use them to handle tasks like this, considering you were running read-only replicas. It is possible to run OpenLDAP in multi-master read-write setup as KDC backends, but you would need to use a different replication mechanism (delta-syncrepl). Delta-synchrepl would be similar to what 389-ds uses for replication and there are some related issues with it too, not really too different from what 389-ds experiences. However, I must add that to fix possible issues in 389-ds replication it is not enough to say 'we are experiencing issues in VM'. Please provide logs and detail of your configuration. It may well be that time drifts in VM cause more harm than actual replication protocol itself. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] user-mod --rename and password
On Thu, 07 May 2015, Jan Pazdziora wrote: Hello, I try to test renaming of user objects. I start with user bob and I'm able to kinit just fine: # echo BobPassword123 | kinit bob Password for b...@example.test: # I then rename the user: # echo Password123 | kinit admin Password for ad...@example.test: # ipa user-mod --rename=bob1 bob Modified user "bob" User login: bob1 First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: b...@example.test UID: 25181 GID: 25181 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True And I try to kinit with the original password and it fails: # echo BobPassword123 | kinit bob1 Password for b...@example.test: kinit: Password incorrect while getting initial credentials # Then I rename the user back and the original password starts to work again: # echo Password123 | kinit admin Password for ad...@example.test: # ipa user-mod --rename=bob bob1 Modified user "bob1" User login: bob First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: b...@example.test UID: 25181 GID: 25181 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True # echo BobPassword123 | kinit bob Password for b...@example.test: # Is this expected? It's with 4.1.0. Yes, we have a bug for this, actually, few of them: https://fedorahosted.org/freeipa/ticket/4757 The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914 -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] user-mod --rename and password
On Thu, 07 May 2015, Rob Crittenden wrote: Alexander Bokovoy wrote: On Thu, 07 May 2015, Jan Pazdziora wrote: Hello, I try to test renaming of user objects. I start with user bob and I'm able to kinit just fine: # echo BobPassword123 | kinit bob Password for b...@example.test: # I then rename the user: # echo Password123 | kinit admin Password for ad...@example.test: # ipa user-mod --rename=bob1 bob Modified user "bob" User login: bob1 First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: b...@example.test UID: 25181 GID: 25181 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True And I try to kinit with the original password and it fails: # echo BobPassword123 | kinit bob1 Password for b...@example.test: kinit: Password incorrect while getting initial credentials # Then I rename the user back and the original password starts to work again: # echo Password123 | kinit admin Password for ad...@example.test: # ipa user-mod --rename=bob bob1 Modified user "bob1" User login: bob First name: Robert Last name: Chase Home directory: /home/bob Login shell: /bin/sh Email address: b...@example.test UID: 25181 GID: 25181 Account disabled: False Password: True Member of HBAC rule: allow_wikiapp Kerberos keys available: True # echo BobPassword123 | kinit bob Password for b...@example.test: # Is this expected? It's with 4.1.0. Yes, we have a bug for this, actually, few of them: https://fedorahosted.org/freeipa/ticket/4757 The actual issue is due to https://fedorahosted.org/freeipa/ticket/4914 Well, in this case the principal isn't changed at all, it's still b...@example.test, which is why the password doesn't work. There probably is no bob1 principal anywhere. Yep, and there is a note in the first bug (#4757) about that. I think ipa user-mod should be doing that rename for krbPrincipalName too but we need to fix password generation via kadmin as well because chances are that users changed their passwords via SSSD which leads to kadmin use. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multi homed environment
On Fri, 08 May 2015, Andy Thompson wrote: I'm trying to roll out IPA in an existing windows environment where everything is multi homed. I did not put my IPA server on all the subnets. I'm having an issue with adding a trust to the domain with the error below ipa: ERROR: CIFS server communication error: code "-1073741801", message "Memory allocation error" (both may be "None") DNS I think since it round robins all the existing A records and is returning IPs out of the local subnet. I don't know much about windows dns services but it's got netmask optimization enabled and doing digs against the service returns the local IP first every time, but pings return them in any order. I've considered adding the DCs to the local hosts file but I'm not sure if that will solve the problem or not. Is that a viable fix? Anyone have any experience in an environment like this? Really not sure what additional problems I will run into with all this multi homed nonsense. Stop here and make sure you obtained the debugging information as described in http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust Without that information it is hard to tell what is happening. Make also sure to tell exact environment (distribution, version, package versions, etc). -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multi homed environment
On Fri, 08 May 2015, Andy Thompson wrote: -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 8:17 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: >I'm trying to roll out IPA in an existing windows environment where >everything is multi homed. I did not put my IPA server on all the >subnets. > >I'm having an issue with adding a trust to the domain with the error >below > >ipa: ERROR: CIFS server communication error: code "-1073741801", > message "Memory allocation error" (both may be >"None") > >DNS I think since it round robins all the existing A records and is >returning IPs out of the local subnet. I don't know much about windows >dns services but it's got netmask optimization enabled and doing digs >against the service returns the local IP first every time, but pings >return them in any order. > >I've considered adding the DCs to the local hosts file but I'm not sure >if that will solve the problem or not. Is that a viable fix? > >Anyone have any experience in an environment like this? Really not >sure what additional problems I will run into with all this multi homed >nonsense. Stop here and make sure you obtained the debugging information as described in http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tru st Without that information it is hard to tell what is happening. Make also sure to tell exact environment (distribution, version, package versions, etc). Well things got ugly. I enabled debug and pointed in the right direction, smb failed to start. Came down to the cifs service was not added when I did the adtrust-install. I tried adding it and it complained that it could not find the A record for the host even though it was there. Thinking something was hung up in resolver cache possibly I restarted the ipa service and it failed completely. Ipactl start fails starting smb because of the missing service and everything fails from there. Is there any way to recover from this mess I just made? :) I assume you have IPA 4.x, i.e. systemd-based environment. 1. Start manually dirsrv@INSTANCE-NAME.service 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. Note that you SHOULD NOT replace $FOO variables below, they should be as specified in the resulting file. For ipa-ldap-updater use see its manual page and my blog: https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ # cat 88-disable-adtrust-extid.update dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService END # ipa-ldap-updater -l ./88-disable-adtrust-extid.update 3. Restart IPA 4. Re-run ipa-adtrust-install and look at the output, including what it appends to /var/log/ipaserver-install.log. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multi homed environment
On Fri, 08 May 2015, Andy Thompson wrote: -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Friday, May 8, 2015 9:40 AM To: Andy Thompson Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] multi homed environment On Fri, 08 May 2015, Andy Thompson wrote: >> -Original Message- >> From: Alexander Bokovoy [mailto:aboko...@redhat.com] >> Sent: Friday, May 8, 2015 8:17 AM >> To: Andy Thompson >> Cc: freeipa-users@redhat.com >> Subject: Re: [Freeipa-users] multi homed environment >> >> On Fri, 08 May 2015, Andy Thompson wrote: >> >I'm trying to roll out IPA in an existing windows environment where >> >everything is multi homed. I did not put my IPA server on all the >> >subnets. >> > >> >I'm having an issue with adding a trust to the domain with the error >> >below >> > >> >ipa: ERROR: CIFS server communication error: code "-1073741801", >> > message "Memory allocation error" (both may be >> >"None") >> > >> >DNS I think since it round robins all the existing A records and is >> >returning IPs out of the local subnet. I don't know much about >> >windows dns services but it's got netmask optimization enabled and >> >doing digs against the service returns the local IP first every >> >time, but pings return them in any order. >> > >> >I've considered adding the DCs to the local hosts file but I'm not >> >sure if that will solve the problem or not. Is that a viable fix? >> > >> >Anyone have any experience in an environment like this? Really not >> >sure what additional problems I will run into with all this multi >> >homed nonsense. >> Stop here and make sure you obtained the debugging information as >> described in >> http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_tr >> u >> st >> >> Without that information it is hard to tell what is happening. >> >> Make also sure to tell exact environment (distribution, version, >> package versions, etc). >> > >Well things got ugly. I enabled debug and pointed in the right >direction, smb failed to start. Came down to the cifs service was not >added when I did the adtrust-install. I tried adding it and it >complained that it could not find the A record for the host even though >it was there. Thinking something was hung up in resolver cache >possibly I restarted the ipa service and it failed completely. > >Ipactl start fails starting smb because of the missing service and >everything fails from there. > >Is there any way to recover from this mess I just made? :) I assume you have IPA 4.x, i.e. systemd-based environment. Yes, sorry forgot to include that. 1. Start manually dirsrv@INSTANCE-NAME.service 2. Disable ADTRUST and EXTID services with ipa-ldap-updater. Note that you SHOULD NOT replace $FOO variables below, they should be as specified in the resulting file. For ipa-ldap-updater use see its manual page and my blog: https://vda.li/en/posts/2015/01/02/playing-with-freeipa-ipa-ldap-updater/ # cat 88-disable-adtrust-extid.update dn: cn=ADTRUST,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService dn: cn=EXTID,cn=$FQDN,cn=masters,cn=ipa,cn=etc,$SUFFIX remove:ipaConfigString:enabledService END # ipa-ldap-updater -l ./88-disable-adtrust-extid.update 3. Restart IPA 4. Re-run ipa-adtrust-install and look at the output, including what it appends to /var/log/ipaserver-install.log. Beautiful, that much is running again, thanks for those pointers. And I'm ashamed to say I tracked down the issue to a fat finger in the resolv.conf file, so it really couldn't look up the needed record :/ So back to the original issue that was in the end because smb wasn't started most likely. I'm still not sure how this will all respond in a multi homed environment like this if the IPA server cannot communicate with all of the interfaces on the DC. Will that cause an issue with the trust or is there anything I need to take into consideration with this? There are few things to consider: 1. IPA master uses DNS SRV records to discover whom to talk to on AD side. Received name from the SRV record is them used by IPA master to connect to the AD DC. 2. AD DCs use DNS SRV records to discover which IPA master to respond to when verifying trust. Received name from the SRV record is then used by AD DC to connect to the IPA master. 3. While right now trust is established using password-based authentication between IPA and AD DCs, actual resolution of identities when trust is in use requires working Kerberos authentication. This might give you a headache in multi-homed environments if the IP returned when resolving AD DC or IPA master would be unreachable. In any case, it is mostly a question of correct routing tables and DNS name resolution. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server principal" and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] HBAC rules don't work with PAM - problem
On Mon, 11 May 2015, Vangass wrote: OK. But the answer granted/declined comes from IPA. So why IPA doesn't check its own HBAC rules at all? Maybe the line 'account required pam_sss.so' isn't necessary/required. I just want to do authentication by IPA HBAC rules. Authentication and account management stages are different in PAM. When authentication is performed, it is separate step. When account management is performed, it is a separate step as well. HBAC rules are checked at account management stage because this is where all such checks are done traditionally in PAM. If you read documentation[1], it states: === The pam_acct_mgmt function is used to determine if the users account is valid. It checks for authentication token and account expiration and verifies access restrictions. It is typically called after the user has been authenticated. === If application doesn't call into pam_acct_mgmt, it is not using PAM stack separation of duties properly. [1] http://linux.die.net/man/3/pam_acct_mgmt -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] some documentation issues
On Tue, 12 May 2015, Arthur Fayzullin wrote: В Пн, 11/05/2015 в 11:35 -0400, Dmitri Pal пишет: AFAIR some time ago we stopped fetching host cert by default. There was no use of it so we decided not issue a cert that has not practical use. -- Thank you, Dmitri Pal Director of Engineering for IdM portfolio Red Hat, Inc. Yes, I have noticed it from reference debian instalation and from EL7&fedora instalation. But this step is present in documentation, and it containes mistake. Please file a documentation bug. Also, I have one question about /etc/ipa/default.conf file. it looks something like this: [global] basedn = dc=,dc= realm = domain = server = . xmlrpc_uri = https://./ipa/xml enable_ra = True is there any way to configure it for HA? in case I will get one freeipa server replica down. IPA command line tools are using SRV records for _ldap._tcp.$DOMAIN to find out list of servers to talk to. The server specified in default.conf is used first but if it fails, connection attempts continue through the list of servers discovered via SRV records. So, you don't need to change anything. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX
On Tue, 12 May 2015, Gould, Joshua wrote: We’re using IPA Server 4.1.0-18. We have a trust between IPA and AD with SID mapping. In our setup, AD would be example.com and IPA would be say ipa.example.com. I’m having some issues configuring both RHEL5 and AIX to work with the compat tree. In both cases, kerberos works with IPA and AD users but LDAP only works with IPA users and not AD users. Should AD users be returned if I search uid=AD_user under cn=users,cn=compat,dc=ipa,dc=example,dc=com? Is this where my RHEL5 and AIX clients should be searching? I’m not getting any matches and I’ve verified that the compat plugin is enabled on our servers. I need a little more to go on as far as if I’m looking in the wrong sub-tree or going about this the wrong way. Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a base cn=compat,dc=ipa,dc=example,dc=com. Simple ldapsearch needs to include proper filter, like what SSSD or nss_ldap are using. slapi-nis is programmed to specifically respond to their queries, not to any request over compat tree. If you want to check from the command line, use a filter like (&(uid=AD_user)(objectclass=posixaccount)) -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust & LDAP Compat mode w/ RHEL5/AIX
On Wed, 13 May 2015, Gould, Joshua wrote: I can login to a RHEL6/7 server as an IPA user and SU to an AD user and it works fine. I can also login directly as an AD user as well. For my RHEL5 system, I can login as a IPA user but can not su - or login as a AD user. -sh-3.2$ su - ad_user su: user goul09 does not exist Have you actually read the definitive guide we have? http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf, linked from http://www.freeipa.org/page/Documentation It looks like you have missed it, given your answers and attempts to use non-fully qualified user names. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-client-install --request-cert ERROR
On Sat, 16 May 2015, Günther J. Niederwimmer wrote: Hello, When I install a IPA client (Centos 7.1) I have this Error in the log. freeipa ERROR certmonger request for host certificate failed Is there a way to become this Certificate back ? I am nearly new on freeIPA and have mach problems :-(. Since FreeIPA 4.1 host certificate is not created by default and failing to fetch it is not an issue. The certificate is not used anywhere. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 18 May 2015, Janelle wrote: On 5/10/15 11:57 PM, Alexander Bokovoy wrote: On Sun, 10 May 2015, Janelle wrote: On 5/5/15 6:47 AM, Dmitri Pal wrote: On 05/04/2015 09:38 PM, Janelle wrote: On 5/4/15 6:06 PM, Nathaniel McCallum wrote: On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: Happy Star Wars Day! May the Fourth be with you! So I have a strange Kerberos problem trying to figure out. On a CLIENT, (CentOS 7.1) if I login to account "usera" they get a ticket as expected. However, if I login to a 6.6 client, it doesn't seem to work. Both were enrolled the same, obviously one is newer. Now, it gets stranger. The "servers" are CentOS 7.1 also. If I login as root, bypassing kerberos, and then do "kinit admin" it works just fine. But if I do "kinit usera" I get: kinit: Generic preauthentication failure while getting initial credentials Which makes no sense. The account works with a 7.1 client but not a 6.x client?? And yet "admin" works, no matter what. What am I missing here? If I had to guess, usera is enabled for OTP-only login. Is that correct? If so, clients require RHEL 7.1 for OTP support. Also, the error you are getting is the result of not enabling FAST support for OTP authentication (see the -T option). Nathaniel Ok, this did give me an idea (Thanks Nathaniel) -- the account was set for BOTH "password" and OTP. Apparently setting both does nothing. Yes a user can login with their password-only, but trying to use kinit does not work. I am not sure I understand where the FAST support or the -T option is to be applied. On kinit? That does not seem correct. Perhaps I am misunderstanding this option? ~J If the user is enabled for OTP his credential are sent differently than in the case when it is not enabled. Effectively instead of using encrypted timestamp the password and OTP are sent to the server as data. But they can't be sent in clear. You need to encrypt the data. To encrypt it you need another key - the host key. The encryption of the data in this context is called tunneling . FAST is the Kerberos protocol feature to provide tunneling of the data sent over the wire. To use FAST one needs to use -T on the kinit command line. Does this help? It helps -- thank you. Now allow me to add a little more fun, and there may not be a solution. From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA-server principal" and it works, gives me a ticket, and if I attempt to login to the web interface, since I already have my ticket - boom, works fine. Now, I enable 2FA and setup a token and change my account to OTP (with TOTP). But as previously discussed, can't seem to specify a -T option from OS X. I know this sounds tricky -- Any ideas? Use kinit --fast-armor-cache /path/to/ccache to specify already existing ccache to armor the FAST processing. This is Heimdal-specific, and you should have Heimdal 1.6rc2 at least. You can check version number by running 'kinit --version'. Aha, so thee default on OS X Yosemite is $ kinit --version kinit (Heimdal 1.5.1apple1) so this won't work? Yes, you have to have the feature in your Kerberos library. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Janelle wrote: > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > On Sun, 10 May 2015, Janelle wrote: > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > Happy Star Wars Day! > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to figure > > > > > > > out. On a > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > they get a > > > > > > > ticket as > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > doesn't seem to > > > > > > > work. > > > > > > > Both were enrolled the same, obviously one is newer. > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > also. If I login > > > > > > > as > > > > > > > root, bypassing kerberos, and then do "kinit admin" it > > > > > > > works just > > > > > > > fine. > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > kinit: Generic preauthentication failure while getting > > > > > > > initial > > > > > > > credentials > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > client but not a > > > > > > > 6.x > > > > > > > client?? And yet "admin" works, no matter what. What am > > > > > > > I missing > > > > > > > here? > > > > > > If I had to guess, usera is enabled for OTP-only login. > > > > > > Is that > > > > > > correct? > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. Also, > > > > > > the error you > > > > > > are getting is the result of not enabling FAST support > > > > > > for OTP > > > > > > authentication (see the -T option). > > > > > > > > > > > > Nathaniel > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > account was set for BOTH "password" and OTP. > > > > > Apparently setting both does nothing. Yes a user can login > > > > > with their password-only, but trying to use kinit does not > > > > > work. > > > > > > > > > > I am not sure I understand where the FAST support or the -T > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > correct. > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > ~J > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > differently than in the case when it is not enabled. > > > > Effectively > > > > instead of using encrypted timestamp the password and OTP are > > > > > > > > sent to the server as data. But they can't be sent in clear. > > > > You > > > > need to encrypt the data. To encrypt it you need another key > > > > - > > > > the host key. The encryption of the data in this context is > > > > called tunneling . FAST is the Kerberos protocol feature to > > > > provide tunneling of the data sent over the wire. To use FAST > > > > > > > > one needs to use -T on the kinit command line. > > > > Does this help? > > > > > > > It helps -- thank you. > > > > > > Now allow me to add a little more fun, and there may not be a > > > solution. > > > > From OS X (Yosemite) I am able to "kinit --kdc-hostname=IPA > > > > -server > > > principal" and it works, gives me a ticket, and if I attempt to > > > > > > login to the web interface, since I already have my ticket - > > > boom, > > > works fine. > > > > > > Now, I enable 2FA and setup a token and change my account to > > > OTP > > > (with TOTP). But as previously discussed, can't seem to > > > specify a > > > -T option from OS X. > > > > > > I know this sounds tricky -- Any ideas? > > Use > > kinit --fast-armor-cache /path/to/ccache to specify already > > existing ccache to armor the FAST processing. > > > > This is Heimdal-specific, and you should have Heimdal 1.6rc2 at > > least. > > You can check version number by running 'kinit --version'. > Aha, so thee default on OS X Yosemite is > > $ kinit --version > kinit (Heimdal 1.5.1apple1) > > so this won't work? Yes, you have to have the feature in your Kerberos library. Browsing the Heimdal source code, I don't even see any support for OTP at all. :( The support is since 1.6rc2, it uses the Richards' draft (draft-richards-otp-kerberos-01.txt) as a base and handles preauth but I don't think anything but login and ftpd supports passing the OTP token. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] interesting Kerberos issue
On Mon, 18 May 2015, Nathaniel McCallum wrote: On Mon, 2015-05-18 at 17:18 +0300, Alexander Bokovoy wrote: On Mon, 18 May 2015, Nathaniel McCallum wrote: > On Mon, 2015-05-18 at 17:03 +0300, Alexander Bokovoy wrote: > > On Mon, 18 May 2015, Janelle wrote: > > > On 5/10/15 11:57 PM, Alexander Bokovoy wrote: > > > > On Sun, 10 May 2015, Janelle wrote: > > > > > On 5/5/15 6:47 AM, Dmitri Pal wrote: > > > > > > On 05/04/2015 09:38 PM, Janelle wrote: > > > > > > > On 5/4/15 6:06 PM, Nathaniel McCallum wrote: > > > > > > > > On Mon, 2015-05-04 at 08:49 -0700, Janelle wrote: > > > > > > > > > Happy Star Wars Day! > > > > > > > > > May the Fourth be with you! > > > > > > > > > > > > > > > > > > So I have a strange Kerberos problem trying to > > > > > > > > > figure > > > > > > > > > out. On a > > > > > > > > > CLIENT, (CentOS 7.1) if I login to account "usera" > > > > > > > > > they get a > > > > > > > > > ticket as > > > > > > > > > expected. However, if I login to a 6.6 client, it > > > > > > > > > doesn't seem to > > > > > > > > > work. > > > > > > > > > Both were enrolled the same, obviously one is > > > > > > > > > newer. > > > > > > > > > > > > > > > > > > Now, it gets stranger. The "servers" are CentOS 7.1 > > > > > > > > > also. If I login > > > > > > > > > as > > > > > > > > > root, bypassing kerberos, and then do "kinit admin" > > > > > > > > > it > > > > > > > > > works just > > > > > > > > > fine. > > > > > > > > > But if I do "kinit usera" I get: > > > > > > > > > > > > > > > > > > kinit: Generic preauthentication failure while > > > > > > > > > getting > > > > > > > > > initial > > > > > > > > > credentials > > > > > > > > > > > > > > > > > > Which makes no sense. The account works with a 7.1 > > > > > > > > > client but not a > > > > > > > > > 6.x > > > > > > > > > client?? And yet "admin" works, no matter what. > > > > > > > > > What am > > > > > > > > > I missing > > > > > > > > > here? > > > > > > > > If I had to guess, usera is enabled for OTP-only > > > > > > > > login. > > > > > > > > Is that > > > > > > > > correct? > > > > > > > > > > > > > > > > If so, clients require RHEL 7.1 for OTP support. > > > > > > > > Also, > > > > > > > > the error you > > > > > > > > are getting is the result of not enabling FAST > > > > > > > > support > > > > > > > > for OTP > > > > > > > > authentication (see the -T option). > > > > > > > > > > > > > > > > Nathaniel > > > > > > > Ok, this did give me an idea (Thanks Nathaniel) -- the > > > > > > > account was set for BOTH "password" and OTP. > > > > > > > Apparently setting both does nothing. Yes a user can > > > > > > > login > > > > > > > with their password-only, but trying to use kinit does > > > > > > > not > > > > > > > work. > > > > > > > > > > > > > > I am not sure I understand where the FAST support or > > > > > > > the -T > > > > > > > > > > > > > > option is to be applied. On kinit? That does not seem > > > > > > > correct. > > > > > > > Perhaps I am misunderstanding this option? > > > > > > > > > > > > > > ~J > > > > > > > > > > > > > If the user is enabled for OTP his credential are sent > > > > > > diff
Re: [Freeipa-users] IPA/AD domain trust - unidirectional or bidirectional?
On Wed, 20 May 2015, opsource trail wrote: Hello, we plan to deploy IPA (Red Hat IdM) trust with AD domain but at the moment we are kind of confused about what type of trust we will need to deal with. In Red Hat documentation we get an information that: "... Trusts, then, are essentially unidirectional. Active Directory users can access IdM resources and services, but IdM users cannot access Active Directory resources... " ( https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/active-directory-trust.html ) I tried to get technical writers to rewrite this sentence but so far unsuccessful. There seems to be some fundamental misunderstanding at hand, unfortunately. On the other hand, when I configure the trust I can clearly see that it is actually bidirectional: [root@ipaserver ~]# ipa trust-add --type=ad adexample.com --admin Administrator --password -- Added Active Directory trust for realm "adexample.com" -- Realm name: adexample.com Domain NetBIOS name: ADEXAMPLE Domain Security Identifier: S-1-5-21-1689615952-3716327440-3249090444 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified I'm afraid that our Windows department will complain and consider this as a security issue. No, it is not a security issue, regardless what your Windows department would like to think. They may better spend time looking into actual Active Directory protocols documentation at https://msdn.microsoft.com/en-us/library/jj712081.aspx to realise situation is much more complex than a binary division between 'secure' and 'insecure'. Is there anybody who could help me understand this? You can start with http://www.freeipa.org/page/V4/One-way_trust to get yourself a high level overview and comparison of what two-way and one-way trust mean in the context of IPA and Active Directory. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] compat settings
On Thu, 21 May 2015, Rudolf Gabler wrote:
Hi to whom it may concern,
we used for many years a 2 location policy to separate email users from
unix users in order to not using the same passwords. So we had 2 trees
in our LDAP with the same user but different passwords.
In freeipa (where we want to migrate now) I can use the accounts and
compat (for email) trees for this purpose and so I added a
dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: userPassword=*
to the compat settings to have a separate place for the password (!not
userPassword=%{userPassword}, because then the accounts password are
mirrored). This works, but I’m not allowed to change the password i.e.
with: ldappasswd -x -D "cn=Directory Manager" -W -S
uid=myuser,cn=users,cn=compat,dc=example,dc=com
I get a result of:
No such object (32)
Additional info: Failed to update password
where as for the accounts tree the ldappasswd is working fine.
What additional setting may be required?
slapi-nis does not support modifying entries in the compat tree. The
tree is virtual, it is re-populated from the original data every time
389-ds server is restarted.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015]
Hi, As per attached message, Fedora 22 final release will come to life next week. If you are planning to use FreeIPA in Fedora 22 or upgrade your FreeIPA deployment to Fedora 22, make sure updates-testing repository is enabled. Several last moment bug fixes related to FreeIPA were not rolled into the final Fedora 22 image and they are waiting in updats-testing for the gates to be open after release. One particular area is support for cross-forest trusts with Active Directory --- Samba in Fedora 22 got upgraded to 4.2.1 version which caused some changes in underlying libraries FreeIPA uses for supporting the cross-forest trust. The fixes are awaiting you after install in the updats-testing. Happy Fedora 22 use! -- / Alexander Bokovoy --- Begin Message --- At the Fedora 22 Final Go/No-Go Meeting #2 that just occurred, it was agreed to Go with the Fedora 22 Final by Fedora QA, Release Engineering and Development. Fedora 22 Final will be publicly available on Tuesday, May 26, 2015. Meeting details can be seen here: Minutes: http://bit.ly/1Bh2pH1 Log: http://bit.ly/1HzMI5g Thank you everyone for a great job, sleepless nights validating TCs, RCs, fixing bugs, composing stuf and everything else needed for smooth releases. Amazing last three years wrangling releases for me! Jaroslav ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct--- End Message --- -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] [[Test-Announce] Fedora 22 Final status is Go, release on May 26, 2015]
On Fri, 22 May 2015, Carlos Raúl Laguna wrote: Hi Alexander Great news, does this also mean that user created in freeipa are self created/synchronized in the windows ad ? Regtards With cross-forest trust we don't synchronize anything to AD. Think about it as if FreeIPA was a separate AD forest, two AD forests don't synchronize anything to each other, they _refer_ to each other's domain controllers for operations that require authentication or other changes. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SSH GSSAPI + FreeIPA with Windows 2008 Trust
On Mon, 25 May 2015, crony wrote: Hi All, we have setup FreeIPA 4.1 (Centos 7) Trust with Windows 2008R2. All (HBAC, SUDO) works pretty well except SSH SSO using GSSAPI from Windows AD clients (ex. putty) to Linux client machines (Centos 6). Password authentication works, just gssapi fails. Do you have have anything in the SSH server logs when using high enough debug level? SSH GSSAPI (single sign-on) should just work fine. On contrary, delegation or forwarding of credentials (i.e. Kerberos TGT from AD side being available after login to SSH server) should not work unless ok-as-delegate flag is set on the host principal -- see 'ipa host-mod --ok-as-delegate=TRUE'. So what exactly is not working: 1. Logging in without entering a password from AD-joined Windows station with PuTTY? 2. Logging in without the password works but no Kerberos ticket available in the shell? 3. Logging in always requires password and then Kerberos ticket is not available in the shell? 4. Something else? Actually, there is one scenario where SSH GSSAPI authentication works -> when connecting to FreeIPA master or replica (trust were established here), but not to FreeIPA host clients. Important sections of configuration files (servers/clients): /etc/ssh/sshd_config: GSSAPIAuthentication yes KerberosAuthentication yes Remove 'KerberosAuthentication yes', you don't want it to be used, only GSSAPI. /etc/krb5.conf: auth_to_local = RULE:[1:$1 $0](^.* WINDOWS.DOMAIN$)s/ WINDOWS.DOMAIN/ windows.domain/ auth_to_local = DEFAULT You don't need to specify auth_to_local rules in krb5.conf in RHEL 7.1 because we now have this filled in by SSSD. As you are claiming FreeIPA 4.1 is in use, it means CentOS 7.1, thus SSSD automatically contributing auth_to_local plugin. BTW. after I log in by password to linux client machine I can use gssapi within the same host by ssh-ing in a loop to the localhost, so locally GSSAPI works here. This is expected and is by design. Is there something I missed? Any help would be greatly appreciated. Answer my questions above, I suspect all you need is to mark the host principal as available for delegation. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
