Bug 1305533
Summary: | ipa trust-add succeded but after that ipa trust-find returns "0 trusts matched" | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Silvio Wanka <Silvio.Wanka> | |
Component: | ipa | Assignee: | IPA Maintainers <ipa-maint> | |
Status: | CLOSED ERRATA | QA Contact: | Namita Soman <nsoman> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 7.2 | CC: | abokovoy, ekeck, jcholast, ksiddiqu, mbasti, mkosek, mvarun, pvoborni, rcritten, sbose, Silvio.Wanka | |
Target Milestone: | rc | Keywords: | ZStream | |
Target Release: | --- | |||
Hardware: | All | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | ipa-4.2.0-16.el7 | Doc Type: | Bug Fix | |
Doc Text: |
Cause:
When upgrading from IPA version prior to 4.2 or installing 4.2 version from scratch, new IPA sidgen and exdom plugins' configuration contained improper value of basedn (literally "$SUFFIX") instead of basedn of the IPA LDAP tree.
Consequence:
Security Identifiers (SIDs) for IPA users and objects were not generated properly due to misconfigured sidgen plugin. As result, all AD trusts created on affected version of IPA did not work while advertising that the trust was established correctly.
Fix:
Configuration of the sidgen and extdom plugins have been fixed as part of the server upgrade to this version. Trusts to AD forests must be re-created manually (by 'ipa trust-add' command). User warnings have been added to inform user that a trust to AD must be recreated.
Result:
After recreating the broken AD trusts, the AD trusts should work as expected.
|
Story Points: | --- | |
Clone Of: | ||||
: | 1311470 (view as bug list) | Environment: | ||
Last Closed: | 2016-11-04 05:51:07 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1311470 |
Description
Silvio Wanka
2016-02-08 14:25:38 UTC
The problems with NetBIOS names are also reported in Bug 1259020, but here it is not only cosmetic, I can't create the trust. And if I check my configuration of the IdM server: # hostname -s dedcs1-idm02 # net registry enumerate_recursive 'HKLM\Software\Samba\smbconf'| sed -n '/netbios/,/Value/p' Valuename = netbios name Type = REG_SZ Value = "DEDCS1IDM02" The dash is removed, why? Successful trust-add indicates that trust object was added, trust-find doesn't suggest that. trust-find can also return no result if user doesn't have read rights for the object. Could you examine, if the trust object actually exists in directory, e.g. with search with directory manager credentials: ldapsearch -D "cn=Directory Manager" -W -b cn=ad,cn=trusts,$suffix where $suffix is the IPA domain, e.g. dc=example,dc=com Dash is removed because it is not in allowed characters atm - bug 1259020 Dash is an allowed character see my link to Microsoft. I have fixed it in meantime in ipaserver/install/adtrustinstance.py. This is a bug and should be solved a.s.a.p. Now to the requested info: # extended LDIF # # LDAPv3 # base <cn=ad,cn=trusts,dc=ipa,dc=company,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # ad, trusts, ipa.company.com dn: cn=ad,cn=trusts,dc=ipa,dc=company,dc=com objectClass: nsContainer objectClass: top cn: cn cn: ad # ad-company.com, ad, trusts, ipa.company.com dn: cn=ad-company.com,cn=ad,cn=trusts,dc=ipa,dc=company,dc=com objectClass: ipaNTTrustedDomain objectClass: ipaIDobject objectClass: top ipaNTFlatName: AD-COMPANY ipaNTTrustPartner: ad-company.com ipaNTTrustedDomainSID: S-1-5-21-3887535394-2959451343-2250752628 ipaNTTrustType: 2 ipaNTTrustDirection: 1 ipaNTTrustPosixOffset: 0 ipaNTSupportedEncryptionTypes: 28 ipaNTTrustAuthOutgoing:: AQAAAAwAAAAcAQAAgI8mK3hi0QECAAAAAAEAAGYAVQA0AHMAcABpA GoANABjAGEAcgApAEMAXwBRAFoAQQA7ADcARwA3AFkATgApAEsATgA+AE4ANgA6ADUAPQBLADwAOA BNADsAaQBSAEUAQgBPAEEAWwBKAFkAJgBOADcAVQBFAG4AeABpADcAOwBIAEcASwBKADUAOgBFAEc AagBhAC4AdwApAGYAMwA3AC0AbABQADoASAA+ADkAawByAEgATQBzACUAUAB6AD0AOABLAE0ANwA/ AEgATAAlADUAKwBQAEcAZwB2ACEAOQBDAEIASgB0AEIAJQA7AGQARwBPAGgAaQBjAEEAaAA+AFAAM QBYAEUAQQAjAEUAQQA= ipaNTTrustAuthIncoming:: AQAAAAwAAAAcAQAAgI8mK3hi0QECAAAAAAEAAGYAVQA0AHMAcABpA GoANABjAGEAcgApAEMAXwBRAFoAQQA7ADcARwA3AFkATgApAEsATgA+AE4ANgA6ADUAPQBLADwAOA BNADsAaQBSAEUAQgBPAEEAWwBKAFkAJgBOADcAVQBFAG4AeABpADcAOwBIAEcASwBKADUAOgBFAEc AagBhAC4AdwApAGYAMwA3AC0AbABQADoASAA+ADkAawByAEgATQBzACUAUAB6AD0AOABLAE0ANwA/ AEgATAAlADUAKwBQAEcAZwB2ACEAOQBDAEIASgB0AEIAJQA7AGQARwBPAGgAaQBjAEEAaAA+AFAAM QBYAEUAQQAjAEUAQQA= ipaNTSIDBlacklistIncoming: S-1-0 ipaNTSIDBlacklistIncoming: S-1-1 ipaNTSIDBlacklistIncoming: S-1-2 ipaNTSIDBlacklistIncoming: S-1-3 ipaNTSIDBlacklistIncoming: S-1-5-1 ipaNTSIDBlacklistIncoming: S-1-5-2 ipaNTSIDBlacklistIncoming: S-1-5-3 ipaNTSIDBlacklistIncoming: S-1-5-4 ipaNTSIDBlacklistIncoming: S-1-5-5 ipaNTSIDBlacklistIncoming: S-1-5-6 ipaNTSIDBlacklistIncoming: S-1-5-7 ipaNTSIDBlacklistIncoming: S-1-5-8 ipaNTSIDBlacklistIncoming: S-1-5-9 ipaNTSIDBlacklistIncoming: S-1-5-10 ipaNTSIDBlacklistIncoming: S-1-5-11 ipaNTSIDBlacklistIncoming: S-1-5-12 ipaNTSIDBlacklistIncoming: S-1-5-13 ipaNTSIDBlacklistIncoming: S-1-5-14 ipaNTSIDBlacklistIncoming: S-1-5-15 ipaNTSIDBlacklistIncoming: S-1-5-16 ipaNTSIDBlacklistIncoming: S-1-5-17 ipaNTSIDBlacklistIncoming: S-1-5-18 ipaNTSIDBlacklistIncoming: S-1-5-19 ipaNTSIDBlacklistIncoming: S-1-5-20 ipaNTSIDBlacklistOutgoing: S-1-0 ipaNTSIDBlacklistOutgoing: S-1-1 ipaNTSIDBlacklistOutgoing: S-1-2 ipaNTSIDBlacklistOutgoing: S-1-3 ipaNTSIDBlacklistOutgoing: S-1-5-1 ipaNTSIDBlacklistOutgoing: S-1-5-2 ipaNTSIDBlacklistOutgoing: S-1-5-3 ipaNTSIDBlacklistOutgoing: S-1-5-4 ipaNTSIDBlacklistOutgoing: S-1-5-5 ipaNTSIDBlacklistOutgoing: S-1-5-6 ipaNTSIDBlacklistOutgoing: S-1-5-7 ipaNTSIDBlacklistOutgoing: S-1-5-8 ipaNTSIDBlacklistOutgoing: S-1-5-9 ipaNTSIDBlacklistOutgoing: S-1-5-10 ipaNTSIDBlacklistOutgoing: S-1-5-11 ipaNTSIDBlacklistOutgoing: S-1-5-12 ipaNTSIDBlacklistOutgoing: S-1-5-13 ipaNTSIDBlacklistOutgoing: S-1-5-14 ipaNTSIDBlacklistOutgoing: S-1-5-15 ipaNTSIDBlacklistOutgoing: S-1-5-16 ipaNTSIDBlacklistOutgoing: S-1-5-17 ipaNTSIDBlacklistOutgoing: S-1-5-18 ipaNTSIDBlacklistOutgoing: S-1-5-19 ipaNTSIDBlacklistOutgoing: S-1-5-20 cn: ad-company.com uidNumber: 645800006 # krbtgt/IPA.COMPANY.COM, ad-company.com, ad, trusts, ipa.company.com dn: krbPrincipalName=krbtgt/IPA.COMPANY.COM,cn=ad-company.com,cn=ad,c n=trusts,dc=ipa,dc=company,dc=com krbExtraData:: AAL7nbhWa3JidGd0L0lQQS5GSUVHRS5DT01AQUQtRklFR0UuQ09NAA== krbLastPwdChange: 20160208135403Z krbPrincipalKey:: MIIBZ6ADAgEBoQMCAQGiAwIBAaMDAgEBpIIBTzCCAUswd6AqMCigAwIBAKEh BB9BRC1GSUVHRS5DT01rcmJ0Z3RJUEEuRklFR0UuQ09NoUkwR6ADAgESoUAEPiAAhzKcr4ZlIX7pD 1vysnRmcKnT0C/oYf80PlXSgIZHOuxtqJqvUZ1dc0cnu5PFzN/kPMvWjckqObpwMfcCMGegKjAooA MCAQChIQQfQUQtRklFR0UuQ09Na3JidGd0SVBBLkZJRUdFLkNPTaE5MDegAwIBEaEwBC4QAB9ybz1 MyRmjbo6vCrk6bjU2D/wsLSCVXi6yByFuJ2qJ/CvWgzL6gl0v7ir1MGegKjAooAMCAQChIQQfQUQt RklFR0UuQ09Na3JidGd0SVBBLkZJRUdFLkNPTaE5MDegAwIBF6EwBC4QAAUK7Lai2UG8YyktU1kEC NquLn4q0fsVx5ITnfTNE+Mzp06FAvTAdz7mkbB7 objectClass: krbPrincipal objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux objectClass: top krbPrincipalName: krbtgt/IPA.COMPANY.COM # IPA4COMPANY$@AD-COMPANY.COM, ad-company.com, ad, trusts, ipa.company.com dn: krbPrincipalName=IPA4COMPANY$@AD-COMPANY.COM,cn=ad-company.com,cn=ad,cn=trusts,d c=ipa,dc=company,dc=com krbExtraData:: AAL7nbhWSVBBNEZJRUdFJEBBRC1GSUVHRS5DT00A krbLastPwdChange: 20160208135403Z krbPrincipalKey:: MIIBW6ADAgEBoQMCAQGiAwIBAaMDAgEBpIIBQzCCAT8wc6AmMCSgAwIBAKEd BBtBRC1GSUVHRS5DT01rcmJ0Z3RJUEE0RklFR0WhSTBHoAMCARKhQAQ+IABx/Ol+z2vB6C0iOHedC mawPPWolnebdgFVqU0C+rOZCT1rOyRW2C1PGXzUliPWtlilfTQhgijNZR2qWkYwY6AmMCSgAwIBAK EdBBtBRC1GSUVHRS5DT01rcmJ0Z3RJUEE0RklFR0WhOTA3oAMCARGhMAQuEABn4AHhqp9KKbW9zbD pY1rOo0pIK/IY4h1qGB9wrrMaUgX2Q7ad+zwKaDwfmDBjoCYwJKADAgEAoR0EG0FELUZJRUdFLkNP TWtyYnRndElQQTRGSUVHRaE5MDegAwIBF6EwBC4QAPMcRnUsjvrexUBaZ2lSr7XVojf4Q+OOQyE8x ic2fPOQNlVKIbgA81UAQZ/K objectClass: krbPrincipal objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux objectClass: ipaAllowedOperations objectClass: top krbPrincipalName: IPA4COMPANY$@AD-COMPANY.COM krbTicketFlags: 64 ipaAllowedToPerform;read_keys: cn=adtrust agents,cn=sysaccounts,cn=etc,dc=ipa, dc=company,dc=com ipaAllowedToPerform;read_keys: cn=trust admins,cn=groups,cn=accounts,dc=ipa,dc =company,dc=com # search result search: 2 result: 0 Success # numResponses: 5 # numEntries: 4 After I have fixed the dash problem for local NetBIOS names, I have rerun ipa-adtrust-install with my prefered NetBIOS name, now this looks good: [HKLM\Software\Samba\smbconf\global] Valuename = workgroup Type = REG_SZ Value = "IPA-COMPANY" Valuename = netbios name Type = REG_SZ Value = "DEDCS1-IDM02" I have deleted the trust infos in LDAP using ldapdelete -r cn=ad-company.com,cn=ad,cn=trusts,dc=ipa,dc=company,dc=com -Y GSS-SPNEGO Recreated the trust, same behavior and results. Here the actual LDAP values: # ldapsearch -b cn=trusts,dc=ipa,dc=company,dc=com -Y GSS-SPNEGO SASL/GSS-SPNEGO authentication started SASL username: admin.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <cn=trusts,dc=ipa,dc=company,dc=com> with scope subtree # filter: (objectclass=*) # requesting: ALL # # trusts, ipa.company.com dn: cn=trusts,dc=ipa,dc=company,dc=com objectClass: nsContainer objectClass: top cn: trusts # ad, trusts, ipa.company.com dn: cn=ad,cn=trusts,dc=ipa,dc=company,dc=com objectClass: nsContainer objectClass: top cn: cn cn: ad # ad-company.com, ad, trusts, ipa.company.com dn: cn=ad-company.com,cn=ad,cn=trusts,dc=ipa,dc=company,dc=com objectClass: ipaNTTrustedDomain objectClass: ipaIDobject objectClass: top ipaNTFlatName: AD-COMPANY ipaNTTrustPartner: ad-company.com ipaNTTrustedDomainSID: S-1-5-21-3887535394-2959451343-2250752628 ipaNTTrustType: 2 ipaNTTrustDirection: 1 ipaNTTrustPosixOffset: 0 ipaNTSupportedEncryptionTypes: 28 ipaNTTrustAuthOutgoing:: AQAAAAwAAAAcAQAAACAwJt9j0QECAAAAAAEAADgAWgByACsAVQB3A EwATAAkAC4AYgBsAFYAVgA5AFkANgB6ADQAXwBhAC0AWwAuAGwAJQAhAFYAcwBOACsAOwBHAHIAQQ A0AGIAKwA8AEYAQwA6AFcAZQBPAGMARABUAGoAawBaACsALQBCAHcALQBlAGkALABJACkATgBKAFo ASgBwADoAWwA6AHMALABZAEoAcwBHAFkASwB4ACsANABpACYAPQA6AHoAJAB+AEYAUwBlADwAZgAp AEYARwBQAGcAZAA2AEYAUwBxAEsAMgBMAHQAYQBPADcAbQBEAFQAPQA4AGQAYQBaAGUAcgA3AHAAO ABFAEYAQgBXAE4ANgA= ipaNTTrustAuthIncoming:: AQAAAAwAAAAcAQAAACAwJt9j0QECAAAAAAEAADgAWgByACsAVQB3A EwATAAkAC4AYgBsAFYAVgA5AFkANgB6ADQAXwBhAC0AWwAuAGwAJQAhAFYAcwBOACsAOwBHAHIAQQ A0AGIAKwA8AEYAQwA6AFcAZQBPAGMARABUAGoAawBaACsALQBCAHcALQBlAGkALABJACkATgBKAFo ASgBwADoAWwA6AHMALABZAEoAcwBHAFkASwB4ACsANABpACYAPQA6AHoAJAB+AEYAUwBlADwAZgAp AEYARwBQAGcAZAA2AEYAUwBxAEsAMgBMAHQAYQBPADcAbQBEAFQAPQA4AGQAYQBaAGUAcgA3AHAAO ABFAEYAQgBXAE4ANgA= ipaNTSIDBlacklistIncoming: S-1-0 ipaNTSIDBlacklistIncoming: S-1-1 ipaNTSIDBlacklistIncoming: S-1-2 ipaNTSIDBlacklistIncoming: S-1-3 ipaNTSIDBlacklistIncoming: S-1-5-1 ipaNTSIDBlacklistIncoming: S-1-5-2 ipaNTSIDBlacklistIncoming: S-1-5-3 ipaNTSIDBlacklistIncoming: S-1-5-4 ipaNTSIDBlacklistIncoming: S-1-5-5 ipaNTSIDBlacklistIncoming: S-1-5-6 ipaNTSIDBlacklistIncoming: S-1-5-7 ipaNTSIDBlacklistIncoming: S-1-5-8 ipaNTSIDBlacklistIncoming: S-1-5-9 ipaNTSIDBlacklistIncoming: S-1-5-10 ipaNTSIDBlacklistIncoming: S-1-5-11 ipaNTSIDBlacklistIncoming: S-1-5-12 ipaNTSIDBlacklistIncoming: S-1-5-13 ipaNTSIDBlacklistIncoming: S-1-5-14 ipaNTSIDBlacklistIncoming: S-1-5-15 ipaNTSIDBlacklistIncoming: S-1-5-16 ipaNTSIDBlacklistIncoming: S-1-5-17 ipaNTSIDBlacklistIncoming: S-1-5-18 ipaNTSIDBlacklistIncoming: S-1-5-19 ipaNTSIDBlacklistIncoming: S-1-5-20 ipaNTSIDBlacklistOutgoing: S-1-0 ipaNTSIDBlacklistOutgoing: S-1-1 ipaNTSIDBlacklistOutgoing: S-1-2 ipaNTSIDBlacklistOutgoing: S-1-3 ipaNTSIDBlacklistOutgoing: S-1-5-1 ipaNTSIDBlacklistOutgoing: S-1-5-2 ipaNTSIDBlacklistOutgoing: S-1-5-3 ipaNTSIDBlacklistOutgoing: S-1-5-4 ipaNTSIDBlacklistOutgoing: S-1-5-5 ipaNTSIDBlacklistOutgoing: S-1-5-6 ipaNTSIDBlacklistOutgoing: S-1-5-7 ipaNTSIDBlacklistOutgoing: S-1-5-8 ipaNTSIDBlacklistOutgoing: S-1-5-9 ipaNTSIDBlacklistOutgoing: S-1-5-10 ipaNTSIDBlacklistOutgoing: S-1-5-11 ipaNTSIDBlacklistOutgoing: S-1-5-12 ipaNTSIDBlacklistOutgoing: S-1-5-13 ipaNTSIDBlacklistOutgoing: S-1-5-14 ipaNTSIDBlacklistOutgoing: S-1-5-15 ipaNTSIDBlacklistOutgoing: S-1-5-16 ipaNTSIDBlacklistOutgoing: S-1-5-17 ipaNTSIDBlacklistOutgoing: S-1-5-18 ipaNTSIDBlacklistOutgoing: S-1-5-19 ipaNTSIDBlacklistOutgoing: S-1-5-20 cn: ad-company.com uidNumber: 645800007 # krbtgt/IPA.COMPANY.COM, ad-company.com, ad, trusts, ipa.company.com dn: krbPrincipalName=krbtgt/IPA.COMPANY.COM,cn=ad-company.com,cn=ad,c n=trusts,dc=ipa,dc=company,dc=com krbExtraData:: AAJA+LpWa3JidGd0L0lQQS5GSUVHRS5DT01AQUQtRklFR0UuQ09NAA== krbLastPwdChange: 20160210084344Z objectClass: krbPrincipal objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux objectClass: top krbPrincipalName: krbtgt/IPA.COMPANY.COM # IPA-COMPANY$@AD-COMPANY.COM, ad-company.com, ad, trusts, ipa.company.com dn: krbPrincipalName=IPA-COMPANY$@AD-COMPANY.COM,cn=ad-company.com,cn=ad,cn=trusts,d c=ipa,dc=company,dc=com krbExtraData:: AAJA+LpWSVBBLUZJRUdFJEBBRC1GSUVHRS5DT00A krbLastPwdChange: 20160210084344Z objectClass: krbPrincipal objectClass: krbPrincipalAux objectClass: krbTicketPolicyAux objectClass: ipaAllowedOperations objectClass: top krbPrincipalName: IPA-COMPANY$@AD-COMPANY.COM krbTicketFlags: 64 ipaAllowedToPerform;read_keys: cn=adtrust agents,cn=sysaccounts,cn=etc,dc=ipa, dc=company,dc=com ipaAllowedToPerform;read_keys: cn=trust admins,cn=groups,cn=accounts,dc=ipa,dc =company,dc=com # search result search: 4 result: 0 Success # numResponses: 6 # numEntries: 5 I have tried to debug "ipa trust-find" but I'm a perl profi and have no expirences with python. For me it looks so that the script ask via https not via LDAP, but in the web interface is also no trust shown. And I work as root but with "kinit admin" before, so I should have the necessary rights. Also on the web interface I was logged on as "admin". trust-find internally does following search: SRCH base="cn=trusts,$SUFFIX" scope=2 filter="(&(objectClass=ipaNTTrustedDomain)(ipaNTSecurityIdentifier=*))" attrs="ipaNTTrustedDomainSID cn ipaNTTrustType ipaNTFlatName" I.e. it requires ipaNTSecurityIdentifier to have a value. It the ldapsearch outputs above this attribute is not present. Next step is to find out why. Tomas, could you advise? Let us get back to basic debugging. Use http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust to generate proper debug information and send it to me. Please don't add it here and don't do just dumps of ldapsearch output as it may contain sensitive information. Was this a fresh installation of ipa-4.2.0 or an update from a previous one? I would assume an update because there is an update issue which does not configure the sidgen plugin properly and hence new objects like the trusted domain object do net get a SID assigned. You can check this by calling ldapsearch -H ldapi://%2fvar%2frun%2fslapd-IPA-COMPANY-COM.socket -b cn=config '(|(cn=IPA SIDGEN)(cn=ipa_extdom_extop))' nsslapd-basedn If you see in the output 'nsslapd-basedn: $SUFFIX' then the sidgen plugin (and the extdom plugin) are not configured correctly. You can fix this manually with ldapmodify by setting nsslapd-basedn to 'dc=ipa,dc=company,dc=com'. You can add the missing SID to the trusted domain object by calling the sidgen task manually or by calling 'ipa-adtrust-install --add-sids'. Details about the update issue. With ipa-4.1 the sidgen and extdom plugins are configured by ipa-adtrust-install, with ipa-4.2 the plugins are configured by default. If ipa-4.1 is upgrades to ipa-4.2 and ipa-adtrust-install was not run the plugin must be configured during the update. The templates used to configure the plugin (/usr/share/ipa/ipa-sidgen-conf.ldif and /usr/share/ipa/ipa-extdom-extop-conf.ldif) contain the placeholder variable $SUFFIX which should be replaced by the install or update process. But according the the upgrade log this is not done: 2016-02-16T10:38:19Z INFO [Enable sidgen and extdom plugins by default] 2016-02-16T10:38:19Z DEBUG Loading StateFile from '/var/lib/ipa/sysupgrade/sysupgrade.state' 2016-02-16T10:38:19Z DEBUG Starting external process 2016-02-16T10:38:19Z DEBUG args='/usr/bin/ldapmodify' '-v' '-f' '/usr/share/ipa/ipa-sidgen-conf.ldif' '-H' 'ldapi://%2fvar%2frun%2fslapd-IPA-DOM.socket' '-Y' 'EXTERNAL' 2016-02-16T10:38:19Z DEBUG Process finished, return code=0 2016-02-16T10:38:19Z DEBUG stdout=add objectclass: top nsSlapdPlugin extensibleObject add cn: IPA SIDGEN add nsslapd-pluginpath: libipa_sidgen add nsslapd-plugininitfunc: ipa_sidgen_init add nsslapd-plugintype: postoperation add nsslapd-pluginenabled: on add nsslapd-pluginid: ipa_sidgen_postop add nsslapd-pluginversion: 1.0 add nsslapd-pluginvendor: Red Hat, Inc. add nsslapd-plugindescription: IPA SIDGEN post operation add nsslapd-plugin-depends-on-type: database add nsslapd-basedn: $SUFFIX adding new entry "cn=IPA SIDGEN,cn=plugins,cn=config" modify complete Yes, it looks like a bug https://fedorahosted.org/freeipa/ticket/5665 Upstream ticket: https://fedorahosted.org/freeipa/ticket/5665 (In reply to Sumit Bose from comment #8) > Was this a fresh installation of ipa-4.2.0 or an update from a previous one? Yes, this was an update. I have setup this Server with 7.1 and also created the IPA domain with 7.1 but the trust creation was done later after upgrade to 7.2. I'm realy wounder about the IPA versions contained in 7.x. But bugzilla is not the right place to this and I will contact you directly to get an explanation. I will try to fix it according your guide. Br, Silvio Wanka Silvio, thanks for the update. This confirms my suspicion. You need to replace nsslapd-basedn value for sidgen and extdom plugin definitions with actual IPA subtree suffix. An easiest way to do so is to use ipa-ldap-updater: ------------------------------------------------------------ # cat ./50-sidgen-extop-basedn.update dn: cn=IPA SIDGEN,cn=plugins,cn=config replace:nsslapd-basedn:$$SUFFIX::$SUFFIX dn: cn=ipa_extdom_extop,cn=plugins,cn=config replace:nsslapd-basedn:$$SUFFIX::$SUFFIX # ipa-ldap-updater ./50-sidgen-extop-basedn.update Update complete The ipa-ldap-updater command was successful ----------------------------------------------------------- Then re-start IdM and re-run ipa-adtrust-install --add-sids again to generate missing SIDs. When IPA is updated to version 4.2 or later, a configuration is added on IPA master to allow sidgen and extdom plugins to be active even without ipa-adtrust-install being run. This configuration contained a bug where $SUFFIX variable in a template was not expanded to your LDAP suffix value (dc=example,dc=com). When ipa-adtrust-install was run on such machine later, it did not change already existing configuration. We are working on a proper fix but the sequence above should help to solve the problem right now. (In reply to Alexander Bokovoy from comment #15) Alexander, thanks for the guide, it works. After that I have repeated the "ipa trust-add", the trust was shown but I was not able to use it. According documentation I should try to get a Kerberos ticket from an AD server, but I got always this: [root@dedcs1-idm02 ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: admin.COM Valid starting Expires Service principal 02/17/2016 16:36:25 02/18/2016 16:22:48 host/dedcs1-idm02.ipa.company.com.COM 02/17/2016 16:27:04 02/18/2016 16:22:48 HTTP/dedcs1-idm02.ipa.company.com.COM 02/17/2016 16:26:43 02/18/2016 16:22:48 ldap/dedcs1-idm02.ipa.company.com.COM 02/17/2016 16:22:50 02/18/2016 16:22:48 krbtgt/IPA.COMPANY.COM.COM [root@dedcs1-idm02 ~]# kvno -S cifs dc001.ad-company.com kvno: Server krbtgt/AD-COMPANY.COM.COM not found in Kerberos database while getting credentials for cifs/tosdead01.ad-company.com And if I try to add an AD user to an external group via Web-GUI I got always the message that the object for AD-COMPANY does not exists. To try to solve the problems I have called "ipa trust-del" and also deleted the trust on AD site, waited a night for AD replication and then recreated the trust. Now I can add AD users to the external group but "kvno -S cifs dc001.ad-company.com" still does not work. Is this a bug or is the documentation not updated because since 4.0 a one-way trust will be created by default and perhaps this call needs a bidirectional trust? TIA, Silvio Silvio, if you haven't specify --two-way=true when establishing trust in RHEL 7.2, the default direction for the trust is a one-way. This means IPA KDC has no cross-realm krbtgt to AD realm that it can issue to its own principals which you are seeing as the error message: ------------------------------------ Server krbtgt/AD-COMPANY.COM.COM not found in Kerberos database while getting credentials for cifs/tosdead01.ad-company.com ------------------------------------ Given that you can add AD users to the external group, the trust works and SSSD is able to resolve users and groups. So you are correct that the documentation needs to be updated. One-way trust default is part of FreeIPA 4.2, not 4.0, though. (In reply to Alexander Bokovoy from comment #18) Alexander, THX, then I had already the right "nose" ;-) But this shows that to fix $SUFFIX is not enough, either there must be an information that trust which was created after upgrade to 4.2 must be deleted first or you find an automatic fix. And the Red Had documentation (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html) needs to be fixed, maybe others too. BTW, there is in "5.3.1. One-Way and Two-Way Trusts" written "One-way trust is the default mode for creating a trust.". So I had assumed that it was since IPA 4.0 the default. In 5.3.3.2. and 5.3.3.3. you find the guide which I have used (create one-way trust but verify using kvno -S cifs …) . My part is done now but finally I will publish the changes which I have done to solve the problem with dash in NetBIOS name. It is very simple: --- /usr/lib/python2.7/site-packages/ipaserver/install/adtrustinstance.py.orig 2015-07-09 10:57:36.000000000 +0200 +++ /usr/lib/python2.7/site-packages/ipaserver/install/adtrustinstance.py 2016-02-09 12:56:30.394308457 +0100 @@ -44,7 +44,7 @@ from ipaplatform.tasks import tasks -ALLOWED_NETBIOS_CHARS = string.ascii_uppercase + string.digits +ALLOWED_NETBIOS_CHARS = string.ascii_uppercase + string.digits + '-' UPGRADE_ERROR = """ Entry %(dn)s does not exist. Yes, the documentation changes need to be done. Can you please file a documentation bug for this? We are looking into how to make upgrade process to detect the situation with trusts created after RHEL7.2 upgrade, fix the internal objects, and ask to re-do trusts. This will not replace a documentation as upgrade in RPM is non-interactive but we'll be able to tell about it in the logs and in the status of the trust-find/trust-show/etc commands if ipaNTSecurityIdentifier is missing there and thus if trust has to be re-established. Regarding NetBIOS name, we have a separate bug to handle NetBIOS namespace. Correction of documentation requested via Bug 1310131. Fixed upstream master: https://fedorahosted.org/freeipa/changeset/9818e463f5d0a91b300801ee7c8f31f25de402b2 https://fedorahosted.org/freeipa/changeset/70bd7c880259256840f2d4af181fb3e4ca96fcca https://fedorahosted.org/freeipa/changeset/c96822f3e5af57f5f1f062a957778c84ad2b520d https://fedorahosted.org/freeipa/changeset/0accf8ccb64963954dbe7c137d23f52e5901ac4f ipa-4-3: https://fedorahosted.org/freeipa/changeset/f12f8318fdf782f93e1988b616eeaebfc45e0b8c https://fedorahosted.org/freeipa/changeset/9c2797d27989428de573d75e643c2cd74065216f https://fedorahosted.org/freeipa/changeset/7dd4a7a0710fa288a52617eda2f877664fa31513 https://fedorahosted.org/freeipa/changeset/4734012c8063460f93f3b819a5bbcca797f6059e ipa-4-2: https://fedorahosted.org/freeipa/changeset/0ac22cf6fe93bb1e808af03d1cabb6f5424ad57b https://fedorahosted.org/freeipa/changeset/10ca4dfbd89637f84c4bab453be696d867f6646c https://fedorahosted.org/freeipa/changeset/4338161c9d22d170faec78c6609dc8724b96b8f7 https://fedorahosted.org/freeipa/changeset/63d8caf0d105f02decc0b5d865fedf6ad063bc1a Installation of IPA 4.2 may fail with this patchset. upstream fix: master: fcc540bbdc5daa24990940124ec3bd439b05257d Fix connections to DS during installation ipa-4-3: c14fb0b9e0f4cb977e897645126ef7d1bbf9aa9e Fix connections to DS during installation ipa-4-2: e2ef561375c63a375710254f159f75d7318c514d Insure the admin_conn is disconnected on stop 0af81913258b2f4c9841c5baddda146667282b2c Fix connections to DS during installation *** Bug 1317635 has been marked as a duplicate of this bug. *** There is a regression, see bug 1317635 for details but fix it here. Fixed upstream master: https://fedorahosted.org/freeipa/changeset/de8c6d81fd5d0f759ac0201e2c517bcb8b43d960 ipa-4-3: https://fedorahosted.org/freeipa/changeset/1e0208612087e80f673e7ec1f8e050b57b5f1fb7 ipa-4-2: https://fedorahosted.org/freeipa/changeset/fb11384e65d74b6a027bf8cfe9f93e003bba5236 Verified # rpm -qa ipa-server ipa-server-4.4.0-2.1.el7.x86_64 # ipa trust-add --type=ad adtest2.qe --admin Administrator --password Active Directory domain administrator's password: --------------------------------------------------- Added Active Directory trust for realm "adtest2.qe" --------------------------------------------------- Realm name: adtest2.qe Domain NetBIOS name: ADTEST2 Domain Security Identifier: S-1-5-21-1869981227-3608374679-2281468898 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust direction: Trusting forest Trust type: Active Directory domain Trust status: Established and verified # ipa trust-find --------------- 1 trust matched --------------- Realm name: adtest2.qe Domain NetBIOS name: ADTEST2 Domain Security Identifier: S-1-5-21-1869981227-3608374679-2281468898 Trust type: Active Directory domain ---------------------------- Number of entries returned 1 ---------------------------- Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2404.html |