[KE1033238] Unable to resolve User IDs from trusted Domain

[Paul Becker]

Dear Sir or Madam,

my college configured an external trust for our existing Active Directory. We have joined
our Linux Server using realmd and aren't able resolving any user IDs from the new
trusted domain using sssd. I am in fact able to get a Kerberos Ticket with credentials of
the trusted domain. Is this a known issue? Please let me know if I am able to provide any
futher information. Logfiles are attached to this mail.

System requirements:
-  centos7 with sssd 1.12.2-58 joined to active directory domain 'content.zone'.
'content.zone' in turn trusts (one-way, external) the domain 'oew.de'.

Symptoms:
- 'id user(a)oew.de' gives the error message ' GSSAPI Error: Unspecified GSS
failure.  Minor code may provide more information (Server not found in Kerberos
database)]'
- resolving user(a)content.zone works without a hitch.

Error Message:
(Thu Jul 30 09:07:28 2015) [sssd[be[content.zone]]] [sasl_bind_send] (0x0080): Extended
failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor
code may provide more information (Server not found in Kerberos database)]

How to reproduce:
sudo realm join --user="administrator"
--computer-ou=OU=Computers,OU=CAP,DC=content,DC=zone content.zone
sudo systemctl stop sssd; sudo rm -rf /var/lib/sss/db/*; sudo systemctl start sssd
id administrator(a)oew.de


Regards,
Paul Becker

[Dmitri Pal]

On 07/30/2015 03:38 AM, Paul Becker wrote:
>  Dear Sir or Madam,
>
>  my college configured an external trust for our existing Active Directory. We have joined
> our Linux Server using realmd and aren't able resolving any user IDs from the new
> trusted domain using sssd. I am in fact able to get a Kerberos Ticket with credentials of
> the trusted domain. Is this a known issue? Please let me know if I am able to provide any
> futher information. Logfiles are attached to this mail.
>
>  System requirements:
>  -  centos7 with sssd 1.12.2-58 joined to active directory domain 'content.zone'.
> 'content.zone' in turn trusts (one-way, external) the domain 'oew.de'.
I assume it is a cross forest trust.
SSSD does not support cross forest trusts.
https://fedorahosted.org/sssd/ticket/2078
It is unclear how soon we would be able to deliver this capability.

The workaround is to create an IdM domain, put your Linux clients into
that domain and establish forest trusts with both your AD domains. That
is known to work.

http://www.freeipa.org/page/Trusts


>  Symptoms:
>  - 'id user(a)oew.de' gives the error message ' GSSAPI Error: Unspecified GSS
> failure.  Minor code may provide more information (Server not found in Kerberos
> database)]'
>  - resolving user(a)content.zone works without a hitch.
>
>  Error Message:
>  (Thu Jul 30 09:07:28 2015) [sssd[be[content.zone]]] [sasl_bind_send] (0x0080): Extended
> failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor
> code may provide more information (Server not found in Kerberos database)]
>
>  How to reproduce:
>  sudo realm join --user="administrator"
> --computer-ou=OU=Computers,OU=CAP,DC=content,DC=zone content.zone
>  sudo systemctl stop sssd; sudo rm -rf /var/lib/sss/db/*; sudo systemctl start sssd
>  id administrator(a)oew.de
>
>
>  Regards,
>  Paul Becker
>
>
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 

-- 
Thank you,
Dmitri Pal

Engineering Director, Identity Management and Platform Security
Red Hat, Inc.

[Paul Becker]

Thank you for your fast respond! You were right it is indeed a cross forest trust, thank
you for mentioning. An IdM domain is no solution for us at the moment. But we realized
that the cross forest trust is functionally when we reconfigure it to be bidirectional. 

Regards,
Paul Becker


>  Am 30.07.2015 um 16:03 schrieb Dmitri Pal <dpal(a)redhat.com&gt;:
>  
>  On 07/30/2015 03:38 AM, Paul Becker wrote:
> > Dear Sir or Madam,
> > 
> > my college configured an external trust for our existing Active Directory. We have
> joined our Linux Server using realmd and aren't able resolving any user IDs from the
> new trusted domain using sssd. I am in fact able to get a Kerberos Ticket with credentials
> of the trusted domain. Is this a known issue? Please let me know if I am able to provide
> any futher information. Logfiles are attached to this mail.
> > 
> > System requirements:
> > -  centos7 with sssd 1.12.2-58 joined to active directory domain
> 'content.zone'. 'content.zone' in turn trusts (one-way, external) the
> domain 'oew.de'.
>  
>  I assume it is a cross forest trust.
>  SSSD does not support cross forest trusts.
>  https://fedorahosted.org/sssd/ticket/2078
> <https://fedorahosted.org/sssd/ticket/2078>
>  It is unclear how soon we would be able to deliver this capability.
>  
>  The workaround is to create an IdM domain, put your Linux clients into that domain and
> establish forest trusts with both your AD domains. That is known to work.
>  
>  http://www.freeipa.org/page/Trusts <http://www.freeipa.org/page/Trusts>
>  
>  
> > Symptoms:
> > - 'id user(a)oew.de <mailto:[e-mail]>' gives the error message '
> GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server
> not found in Kerberos database)]'
> > - resolving user(a)content.zone <mailto:[e-mail]> works without a
> hitch.
> > 
> > Error Message:
> > (Thu Jul 30 09:07:28 2015) [sssd[be[content.zone]]] [sasl_bind_send] (0x0080):
> Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS
> failure.  Minor code may provide more information (Server not found in Kerberos
> database)]
> > 
> > How to reproduce:
> > sudo realm join --user="administrator"
> --computer-ou=OU=Computers,OU=CAP,DC=content,DC=zone content.zone
> > sudo systemctl stop sssd; sudo rm -rf /var/lib/sss/db/*; sudo systemctl start sssd
> > id administrator(a)oew.de <mailto:[e-mail]>
> > 
> > 
> > Regards,
> > Paul Becker
> > 
> > 
> > _______________________________________________
> > sssd-users mailing list
> > sssd-users(a)lists.fedorahosted.org <mailto:[e-mail]>
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> <https://lists.fedorahosted.org/mailman/listinfo/sssd-users>
>  
>  
>  -- 
>  Thank you,
>  Dmitri Pal
>  
>  Engineering Director, Identity Management and Platform Security
>  Red Hat, Inc.
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users