RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1305533 - ipa trust-add succeded but after that ipa trust-find returns "0 trusts matched"
Summary: ipa trust-add succeded but after that ipa trust-find returns "0 trusts matched"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa
Version: 7.2
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: IPA Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
: 1317635 (view as bug list)
Depends On:
Blocks: 1311470
TreeView+ depends on / blocked
 
Reported: 2016-02-08 14:25 UTC by Silvio Wanka
Modified: 2019-09-12 09:54 UTC (History)
11 users (show)

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.
Clone Of:
: 1311470 (view as bug list)
Environment:
Last Closed: 2016-11-04 05:51:07 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2404 0 normal SHIPPED_LIVE ipa bug fix and enhancement update 2016-11-03 13:56:18 UTC

Description Silvio Wanka 2016-02-08 14:25:38 UTC 
Description of problem:
I have tried more than three times to add a trust to our AD domain:

# ipa trust-add --type=ad ad-company.com --admin ad-admin
Active Directory domain administrator's password:
-----------------------------------------------------
Added Active Directory trust for realm "ad-company.com"
-----------------------------------------------------
  Realm name: ad-company.com
  Domain NetBIOS name: AD-COMPANY
  Domain Security Identifier: S-1-5-21-3887535394-2959451343-2250752628
  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

But I can't get any Kerberos ticket for AD server and if I try

# ipa trust-find
----------------
0 trusts matched
----------------
----------------------------
Number of entries returned 0
----------------------------

On AD site the trust will be shown in the MMC. And if I add the trust using the web interface I get also success and validated but also there it does not appear in the list.
All DNS checks are OK except that Windows offers the Kerberos SRV record only under TCP and not under UDP as IDM.

Version-Release number of selected component (if applicable):
ipa-python-4.2.0-15.el7.centos.3.x86_64
ipa-admintools-4.2.0-15.el7.centos.3.x86_64
ipa-server-trust-ad-4.2.0-15.el7.centos.3.x86_64
ipa-client-4.2.0-15.el7.centos.3.x86_64
ipa-server-dns-4.2.0-15.el7.centos.3.x86_64
ipa-server-4.2.0-15.el7.centos.3.x86_64

Additional info:
BTW during ipa-adtrust-install I must determine that IPA does not support all according Microsoft allowed characters in NetBIOS names. See https://support.microsoft.com/en-us/kb/909264 so my should be "IPA-COMPANY" because DNS FQDN is ipa.company.com and IPA is IMO to short. But neither dash (minus sign) nor underscore are accepted by ipa-adtrust-install. But I can't change the NetBIOS name of the AD domain which contains a dash!
Comment 2 Silvio Wanka 2016-02-09 08:16:01 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?
Comment 3 Petr Vobornik 2016-02-09 13:02:13 UTC 
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
Comment 4 Silvio Wanka 2016-02-09 13:35:59 UTC 
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
Comment 5 Silvio Wanka 2016-02-10 11:00:20 UTC 
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".
Comment 6 Petr Vobornik 2016-02-11 13:03:48 UTC 
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?
Comment 7 Alexander Bokovoy 2016-02-15 20:46:38 UTC 
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.
Comment 8 Sumit Bose 2016-02-16 11:15:58 UTC 
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
Comment 9 Alexander Bokovoy 2016-02-16 11:24:10 UTC 
Yes, it looks like a bug https://fedorahosted.org/freeipa/ticket/5665
Comment 10 Petr Vobornik 2016-02-16 16:03:49 UTC 
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/5665
Comment 14 Silvio Wanka 2016-02-17 09:42:29 UTC 
(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
Comment 15 Alexander Bokovoy 2016-02-17 09:52:10 UTC 
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.
Comment 17 Silvio Wanka 2016-02-18 08:47:38 UTC 
(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
Comment 18 Alexander Bokovoy 2016-02-18 08:58:18 UTC 
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.
Comment 19 Silvio Wanka 2016-02-18 09:54:33 UTC 
(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.
Comment 20 Alexander Bokovoy 2016-02-18 10:28:46 UTC 
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.
Comment 21 Silvio Wanka 2016-02-19 14:35:40 UTC 
Correction of documentation requested via Bug 1310131.
Comment 22 Martin Bašti 2016-02-23 17:14:31 UTC 
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
Comment 24 Martin Bašti 2016-03-01 16:21:45 UTC 
Installation of IPA 4.2 may fail with this patchset.
Comment 25 Petr Vobornik 2016-03-02 09:45:06 UTC 
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
Comment 28 Petr Vobornik 2016-03-15 15:06:23 UTC 
*** Bug 1317635 has been marked as a duplicate of this bug. ***
Comment 29 Petr Vobornik 2016-03-15 15:08:05 UTC 
There is a regression, see bug 1317635 for details but fix it here.
Comment 30 Petr Vobornik 2016-03-16 16:31:20 UTC 
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
Comment 32 Varun Mylaraiah 2016-07-21 15:29:07 UTC 
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
----------------------------
Comment 34 errata-xmlrpc 2016-11-04 05:51:07 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.