sssd connecting to two AD domains

[Ondrej Valousek]

Hi all,

I have a machine joined to AD domain "mydomain.com" and there is also domain
"mydomain2.com". The two are connected with full two way trust.

SSSD can happily recognize users from "mydomain.com", but fails with users from
"mydomain2.com" - sssd complains that:

(Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of
port 389 for server 'server.mydomain2.com' is 'not working'
(Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable
to complete the full connection request, this internal status does not necessarily
indicate network port issues.

But I can connect to that server with ldapsearch just fine (using a TGT obtained with
kinit -k hostname$).

Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal
"host/hostname@REALM" instead of "hostname$@REALM":


(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] (0x0400): Child
responded: 14 [Client 'host/hostname(a)mydomain.COM' not found in Kerberos
database], expired on [0]
(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get
TGT: 14 [Bad address]
(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_cli_kinit_done] (0x0400): Cannot get a
TGT: ret [1432158226](Authentication Failed)


I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong
principal?
Using RHEL-7.
Thanks,

Ondrej

-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.

[Ondrej Valousek]

Ok, I see that it’s probably not supported:
https://pagure.io/SSSD/sssd/issue/2078
right?
Ondrej

From: Ondrej Valousek [mailto:[e-mail]]
Sent: Monday, July 30, 2018 10:45 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org&gt;
Subject: [SSSD-users] sssd connecting to two AD domains

Hi all,

I have a machine joined to AD domain “mydomain.com” and there is also domain
“mydomain2.com”. The two are connected with full two way trust.

SSSD can happily recognize users from “mydomain.com”, but fails with users from
“mydomain2.com” - sssd complains that:

(Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of
port 389 for server 'server.mydomain2.com' is 'not working'
(Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable
to complete the full connection request, this internal status does not necessarily
indicate network port issues.

But I can connect to that server with ldapsearch just fine (using a TGT obtained with
kinit –k hostname$).

Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal
“host/hostname@REALM” instead of “hostname$@REALM”:


(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] (0x0400): Child
responded: 14 [Client &#39;host/hostname(a)mydomain.COM&#39; not found in Kerberos
database], expired on [0]
(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get
TGT: 14 [Bad address]
(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_cli_kinit_done] (0x0400): Cannot get a
TGT: ret [1432158226](Authentication Failed)


I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong
principal?
Using RHEL-7.
Thanks,

Ondrej

-----



The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to:
[e-mail]<mailto:[e-mail]>. Thank You. Silicon
and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered
Office: South County Business Park, Leopardstown, Dublin 18.



-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.

[Jakub Hrozek]

Are mydomain and mydomain2 coming from a different forest?

with id_provider=ad sssd should work fine with domains from the same forest and it should
pick the right principal. If it doesn’t and setting ldap_sasl_authid to shortname$@realm,
then there must be a bug in the principal selection logic.

>  On 30 Jul 2018, at 11:25, Ondrej Valousek
> <Ondrej.Valousek(a)s3group.com&gt; wrote:
>  
>  Ok, I see that it’s probably not supported:
>  https://pagure.io/SSSD/sssd/issue/2078
>  right?
>  Ondrej
>   
>  From: Ondrej Valousek [mailto:[e-mail]] 
>  Sent: Monday, July 30, 2018 10:45 AM
>  To: End-user discussions about the System Security Services Daemon
> <sssd-users(a)lists.fedorahosted.org&gt;
>  Subject: [SSSD-users] sssd connecting to two AD domains
>   
>  Hi all,
>   
>  I have a machine joined to AD domain “mydomain.com” and there is also domain
> “mydomain2.com”. The two are connected with full two way trust.
>   
>  SSSD can happily recognize users from “mydomain.com”, but fails with users from
> “mydomain2.com” - sssd complains that:
>   
>  (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of
> port 389 for server 'server.mydomain2.com' is 'not working'
>  (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable
> to complete the full connection request, this internal status does not necessarily
> indicate network port issues.
>   
>  But I can connect to that server with ldapsearch just fine (using a TGT obtained with
> kinit –k hostname$).
>   
>  Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal
> “host/hostname@REALM” instead of “hostname$@REALM”:
>   
>   
>  (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] (0x0400): Child
> responded: 14 [Client &#39;host/hostname(a)mydomain.COM&#39; not found in Kerberos
> database], expired on [0]
>  (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get
> TGT: 14 [Bad address]
>  (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_cli_kinit_done] (0x0400): Cannot get
> a TGT: ret [1432158226](Authentication Failed)
>   
>   
>  I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong
> principal?
>  Using RHEL-7.
>  Thanks,
>   
>  Ondrej
>  -----
>   
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>   
>  -----
>  
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: 
>  communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group).
> Registered in Ireland no. 378073. Registered Office: South County Business Park,
> Leopardstown, Dublin 18.
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
>  To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[Ondrej Valousek]

Hi,
No, these are different forests, but a two way trust is established between these two.
Ondrej

-----Original Message-----
From: Jakub Hrozek [mailto:[e-mail]] 
Sent: Monday, August 06, 2018 9:36 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org&gt;
Subject: [SSSD-users] Re: sssd connecting to two AD domains

Are mydomain and mydomain2 coming from a different forest?

with id_provider=ad sssd should work fine with domains from the same forest and it should
pick the right principal. If it doesn’t and setting ldap_sasl_authid to shortname$@realm,
then there must be a bug in the principal selection logic.

>  On 30 Jul 2018, at 11:25, Ondrej Valousek
> <Ondrej.Valousek(a)s3group.com&gt; wrote:
>  
>  Ok, I see that it’s probably not supported:
>  https://pagure.io/SSSD/sssd/issue/2078
>  right?
>  Ondrej
>   
>  From: Ondrej Valousek [mailto:[e-mail]]
>  Sent: Monday, July 30, 2018 10:45 AM
>  To: End-user discussions about the System Security Services Daemon 
>  <sssd-users(a)lists.fedorahosted.org&gt;
>  Subject: [SSSD-users] sssd connecting to two AD domains
>   
>  Hi all,
>   
>  I have a machine joined to AD domain “mydomain.com” and there is also domain
> “mydomain2.com”. The two are connected with full two way trust.
>   
>  SSSD can happily recognize users from “mydomain.com”, but fails with users from
> “mydomain2.com” - sssd complains that:
>   
>  (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of
> port 389 for server 'server.mydomain2.com' is 'not working'
>  (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable
> to complete the full connection request, this internal status does not necessarily
> indicate network port issues.
>   
>  But I can connect to that server with ldapsearch just fine (using a TGT obtained with
> kinit –k hostname$).
>   
>  Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal
> “host/hostname@REALM” instead of “hostname$@REALM”:
>   
>   
>  (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] 
>  (0x0400): Child responded: 14 [Client &#39;host/hostname(a)mydomain.COM&#39; not 
>  found in Kerberos database], expired on [0] (Mon Jul 30 08:32:34 2018) 
>  [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 
>  [Bad address] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] 
>  [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret 
>  [1432158226](Authentication Failed)
>   
>   
>  I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong
> principal?
>  Using RHEL-7.
>  Thanks,
>   
>  Ondrej
>  -----
>   
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>   
>  -----
>  
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: 
>  communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group).
> Registered in Ireland no. 378073. Registered Office: South County Business Park,
> Leopardstown, Dublin 18.
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
>  unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  osted.org/message/5AR2PPJ3ARQDVDTLPWPLN5PSB75HVO6V/
>  
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.

[Ondrej Valousek]

Also, yes, setting ldap_sasl_authid does help, but it's bit awkward as right now I am
using general sssd.conf for all machines.
Having to include ldap_sasl_authid parameter means the configuration file is different for
every machine :-(
Ondrej

-----Original Message-----
From: Ondrej Valousek [mailto:[e-mail]] 
Sent: Monday, August 06, 2018 9:40 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org&gt;
Subject: [SSSD-users] Re: sssd connecting to two AD domains

Hi,
No, these are different forests, but a two way trust is established between these two.
Ondrej

-----Original Message-----
From: Jakub Hrozek [mailto:[e-mail]]
Sent: Monday, August 06, 2018 9:36 AM
To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org&gt;
Subject: [SSSD-users] Re: sssd connecting to two AD domains

Are mydomain and mydomain2 coming from a different forest?

with id_provider=ad sssd should work fine with domains from the same forest and it should
pick the right principal. If it doesn’t and setting ldap_sasl_authid to shortname$@realm,
then there must be a bug in the principal selection logic.

>  On 30 Jul 2018, at 11:25, Ondrej Valousek
> <Ondrej.Valousek(a)s3group.com&gt; wrote:
>  
>  Ok, I see that it’s probably not supported:
>  https://pagure.io/SSSD/sssd/issue/2078
>  right?
>  Ondrej
>   
>  From: Ondrej Valousek [mailto:[e-mail]]
>  Sent: Monday, July 30, 2018 10:45 AM
>  To: End-user discussions about the System Security Services Daemon 
>  <sssd-users(a)lists.fedorahosted.org&gt;
>  Subject: [SSSD-users] sssd connecting to two AD domains
>   
>  Hi all,
>   
>  I have a machine joined to AD domain “mydomain.com” and there is also domain
> “mydomain2.com”. The two are connected with full two way trust.
>   
>  SSSD can happily recognize users from “mydomain.com”, but fails with users from
> “mydomain2.com” - sssd complains that:
>   
>  (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of
> port 389 for server 'server.mydomain2.com' is 'not working'
>  (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable
> to complete the full connection request, this internal status does not necessarily
> indicate network port issues.
>   
>  But I can connect to that server with ldapsearch just fine (using a TGT obtained with
> kinit –k hostname$).
>   
>  Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal
> “host/hostname@REALM” instead of “hostname$@REALM”:
>   
>   
>  (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv]
>  (0x0400): Child responded: 14 [Client &#39;host/hostname(a)mydomain.COM&#39; not 
>  found in Kerberos database], expired on [0] (Mon Jul 30 08:32:34 2018) 
>  [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 
>  [Bad address] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] 
>  [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret 
>  [1432158226](Authentication Failed)
>   
>   
>  I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong
> principal?
>  Using RHEL-7.
>  Thanks,
>   
>  Ondrej
>  -----
>   
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>   
>  -----
>  
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: 
>  communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group).
> Registered in Ireland no. 378073. Registered Office: South County Business Park,
> Leopardstown, Dublin 18.
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
>  unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  osted.org/message/5AR2PPJ3ARQDVDTLPWPLN5PSB75HVO6V/
>  
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.

[Sumit Bose]

On Mon, Aug 06, 2018 at 08:34:04AM +0000, Ondrej Valousek wrote:
>  Also, yes, setting ldap_sasl_authid does help, but it's bit
> awkward as right now I am using general sssd.conf for all machines.
>  Having to include ldap_sasl_authid parameter means the configuration file is different
> for every machine :-( 
Can you share your sssd.conf?

Are you using the AD or LDAP provider? Please note there are different
defaults for the principal for the two providers, AD will use
“hostname$@REALM” while LDAP will use “host/hostname@REALM”.

With two domains I'd always recommend to use two different keytab files
and use krb5_keytab and ldap_krb5_keytab to point at least one domain to
the non-default keytab file.

HTH

bye,
Sumit

> Ondrej
> 
> -----Original Message-----
> From: Ondrej Valousek [mailto:[e-mail]] 
> Sent: Monday, August 06, 2018 9:40 AM
> To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org&gt;
> Subject: [SSSD-users] Re: sssd connecting to two AD domains
> 
> Hi,
> No, these are different forests, but a two way trust is established between these
two.
> Ondrej
> 
> -----Original Message-----
> From: Jakub Hrozek [mailto:[e-mail]]
> Sent: Monday, August 06, 2018 9:36 AM
> To: End-user discussions about the System Security Services Daemon
<sssd-users(a)lists.fedorahosted.org&gt;
> Subject: [SSSD-users] Re: sssd connecting to two AD domains
> 
> Are mydomain and mydomain2 coming from a different forest?
> 
> with id_provider=ad sssd should work fine with domains from the same forest and it
should pick the right principal. If it doesn’t and setting ldap_sasl_authid to
shortname$@realm, then there must be a bug in the principal selection logic.
> 
> > On 30 Jul 2018, at 11:25, Ondrej Valousek <Ondrej.Valousek(a)s3group.com&gt;
wrote:
> > 
> > Ok, I see that it’s probably not supported:
> > https://pagure.io/SSSD/sssd/issue/2078
> > right?
> > Ondrej
> >  
> > From: Ondrej Valousek [mailto:[e-mail]]
> > Sent: Monday, July 30, 2018 10:45 AM
> > To: End-user discussions about the System Security Services Daemon 
> > <sssd-users(a)lists.fedorahosted.org&gt;
> > Subject: [SSSD-users] sssd connecting to two AD domains
> >  
> > Hi all,
> >  
> > I have a machine joined to AD domain “mydomain.com” and there is also domain
“mydomain2.com”. The two are connected with full two way trust.
> >  
> > SSSD can happily recognize users from “mydomain.com”, but fails with users from
“mydomain2.com” - sssd complains that:
> >  
> > (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port
status of port 389 for server 'server.mydomain2.com' is 'not working'
> > (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD
is unable to complete the full connection request, this internal status does not
necessarily indicate network port issues.
> >  
> > But I can connect to that server with ldapsearch just fine (using a TGT obtained
with kinit –k hostname$).
> >  
> > Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong
principal “host/hostname@REALM” instead of “hostname$@REALM”:
> >  
> >  
> > (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv]
> > (0x0400): Child responded: 14 [Client &#39;host/hostname(a)mydomain.COM&#39; not 
> > found in Kerberos database], expired on [0] (Mon Jul 30 08:32:34 2018) 
> > [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 
> > [Bad address] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] 
> > [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret 
> > [1432158226](Authentication Failed)
> >  
> >  
> > I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using
wrong principal?
> > Using RHEL-7.
> > Thanks,
> >  
> > Ondrej
> > -----
> >  
> > The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
> >  
> > -----
> > 
> > The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: 
> > communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3
Group). Registered in Ireland no. 378073. Registered Office: South County Business Park,
Leopardstown, Dublin 18.
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > osted.org/message/5AR2PPJ3ARQDVDTLPWPLN5PSB75HVO6V/
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an
email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...
> 
> -----
> 
> The information contained in this e-mail and in any attachments is confidential and
is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an
email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...
> 
> -----
> 
> The information contained in this e-mail and in any attachments is confidential and
is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

[Ondrej Valousek]

My configuration file (sanitized):
[sssd]
    services = autofs, nss, pam
    config_file_version = 2
    debug_level = 0xFFFF

    domains = default, mydomain2
[nss]

[pam]
    debug_level = 0xFFFF

[domain/default]
    debug_level = 3
    ldap_id_mapping = False
    ad_domain = MYDOMAIN1.COM
    id_provider = ad
    auth_provider = ad
    chpass_provider = ad
    autofs_provider = ad
    cache_credentials = True
# interval (in seconds) to renew Kerberos TGTs
    ldap_user_name = uid
    krb5_renew_interval = 3600

[domain/mydomain2]
    debug_level = 0xFFFF
    ldap_id_mapping = False
    ad_domain = MYDOMAIN2.COM
    id_provider = ad
    auth_provider = ad
    chpass_provider = ad
    autofs_provider = ad
    cache_credentials = True
# interval (in seconds) to renew Kerberos TGTs
    ldap_user_name = uid
    krb5_renew_interval = 3600
# request renewable Kerberos tickets
    krb5_renewable_lifetime = 30d
    krb5_validate = False

The machine is joined to MYDOMAIN1.COM (hence it has only credentials for this domain in
the default krb5.keytab) - but since there is two way trust with MYDOMAIN2.com, it can use
its machine Kerberos principal (granted from MYDOMAIN1)  for searches in both domains.
I tried that, it works well, but only in case I add:
 "Ldap_sasl_authid = MYHOST$(a)MYDOMAIN1.COM" to the [domain/mydomain2] section.

To me, this should not be necessary.
Ondrej


-----Original Message-----
From: Sumit Bose [mailto:[e-mail]] 
Sent: Tuesday, August 07, 2018 1:13 PM
To: sssd-users(a)lists.fedorahosted.org
Subject: [SSSD-users] Re: sssd connecting to two AD domains

On Mon, Aug 06, 2018 at 08:34:04AM +0000, Ondrej Valousek wrote:
>  Also, yes, setting ldap_sasl_authid does help, but it's bit
> awkward as right now I am using general sssd.conf for all machines.
>  Having to include ldap_sasl_authid parameter means the configuration 
>  file is different for every machine :-(
>  
Can you share your sssd.conf?

Are you using the AD or LDAP provider? Please note there are different defaults for the
principal for the two providers, AD will use “hostname$@REALM” while LDAP will use
“host/hostname@REALM”.

With two domains I'd always recommend to use two different keytab files and use
krb5_keytab and ldap_krb5_keytab to point at least one domain to the non-default keytab
file.

HTH

bye,
Sumit

>  Ondrej
>  
>  -----Original Message-----
>  From: Ondrej Valousek [mailto:[e-mail]]
>  Sent: Monday, August 06, 2018 9:40 AM
>  To: End-user discussions about the System Security Services Daemon 
>  <sssd-users(a)lists.fedorahosted.org&gt;
>  Subject: [SSSD-users] Re: sssd connecting to two AD domains
>  
>  Hi,
>  No, these are different forests, but a two way trust is established between these two.
>  Ondrej
>  
>  -----Original Message-----
>  From: Jakub Hrozek [mailto:[e-mail]]
>  Sent: Monday, August 06, 2018 9:36 AM
>  To: End-user discussions about the System Security Services Daemon 
>  <sssd-users(a)lists.fedorahosted.org&gt;
>  Subject: [SSSD-users] Re: sssd connecting to two AD domains
>  
>  Are mydomain and mydomain2 coming from a different forest?
>  
>  with id_provider=ad sssd should work fine with domains from the same forest and it should
> pick the right principal. If it doesn’t and setting ldap_sasl_authid to shortname$@realm,
> then there must be a bug in the principal selection logic.
>  
>  > On 30 Jul 2018, at 11:25, Ondrej Valousek <Ondrej.Valousek(a)s3group.com&gt;
> wrote:
>  > 
>  > Ok, I see that it’s probably not supported:
>  > https://pagure.io/SSSD/sssd/issue/2078
>  > right?
>  > Ondrej
>  >  
>  > From: Ondrej Valousek [mailto:[e-mail]]
>  > Sent: Monday, July 30, 2018 10:45 AM
>  > To: End-user discussions about the System Security Services Daemon 
>  > <sssd-users(a)lists.fedorahosted.org&gt;
>  > Subject: [SSSD-users] sssd connecting to two AD domains
>  >  
>  > Hi all,
>  >  
>  > I have a machine joined to AD domain “mydomain.com” and there is also domain
> “mydomain2.com”. The two are connected with full two way trust.
>  >  
>  > SSSD can happily recognize users from “mydomain.com”, but fails with users from
> “mydomain2.com” - sssd complains that:
>  >  
>  > (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port
> status of port 389 for server 'server.mydomain2.com' is 'not working'
>  > (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is
> unable to complete the full connection request, this internal status does not necessarily
> indicate network port issues.
>  >  
>  > But I can connect to that server with ldapsearch just fine (using a TGT obtained
> with kinit –k hostname$).
>  >  
>  > Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong
> principal “host/hostname@REALM” instead of “hostname$@REALM”:
>  >  
>  >  
>  > (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv]
>  > (0x0400): Child responded: 14 [Client &#39;host/hostname(a)mydomain.COM&#39; 
>  > not found in Kerberos database], expired on [0] (Mon Jul 30 08:32:34 
>  > 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get 
>  > TGT: 14 [Bad address] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] 
>  > [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret 
>  > [1432158226](Authentication Failed)
>  >  
>  >  
>  > I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong
> principal?
>  > Using RHEL-7.
>  > Thanks,
>  >  
>  > Ondrej
>  > -----
>  >  
>  > The information contained in this e-mail and in any attachments is confidential and
> is designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>  >  
>  > -----
>  > 
>  > The information contained in this e-mail and in any attachments is confidential and
> is designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: 
>  > communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3
> Group). Registered in Ireland no. 378073. Registered Office: South County Business Park,
> Leopardstown, Dublin 18.
>  > _______________________________________________
>  > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
>  > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  > List Guidelines: 
>  > https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives: 
>  > https://lists.fedoraproject.org/archives/list/[e-mail]
>  > ah osted.org/message/5AR2PPJ3ARQDVDTLPWPLN5PSB75HVO6V/
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
>  unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  osted.org/message/Z6H27YNJRSOZE6735CWXMKAHAH4STNNG/
>  
>  -----
>  
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
>  unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  osted.org/message/UGEJ6IDFIDIVUJB3TC6CW7UTZ66WYMTZ/
>  
>  -----
>  
>  The information contained in this e-mail and in any attachments is confidential and is
> designated solely for the attention of the intended recipient(s). If you are not an
> intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
> any part thereof. If you have received this e-mail in error, please notify the sender by
> return e-mail and delete all copies of this e-mail from your computer system(s). Please
> direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
> Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
> South County Business Park, Leopardstown, Dublin 18.
>  _______________________________________________
>  sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
>  unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: 
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives: 
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  osted.org/message/7ZBUNYK6K7ZAVFEUTQXRO4ZTK6CFQSF7/
>  
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

-----

The information contained in this e-mail and in any attachments is confidential and is
designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.

[Sumit Bose]

On Tue, Aug 07, 2018 at 01:00:17PM +0000, Ondrej Valousek wrote:
>  My configuration file (sanitized):
>  [sssd]
>      services = autofs, nss, pam
>      config_file_version = 2
>      debug_level = 0xFFFF
>  
>      domains = default, mydomain2
>  [nss]
>  
>  [pam]
>      debug_level = 0xFFFF
>  
>  [domain/default]
>      debug_level = 3
>      ldap_id_mapping = False
>      ad_domain = MYDOMAIN1.COM
>      id_provider = ad
>      auth_provider = ad
>      chpass_provider = ad
>      autofs_provider = ad
>      cache_credentials = True
>  # interval (in seconds) to renew Kerberos TGTs
>      ldap_user_name = uid
>      krb5_renew_interval = 3600
>  
>  [domain/mydomain2]
>      debug_level = 0xFFFF
>      ldap_id_mapping = False
>      ad_domain = MYDOMAIN2.COM
>      id_provider = ad
>      auth_provider = ad
>      chpass_provider = ad
>      autofs_provider = ad
>      cache_credentials = True
>  # interval (in seconds) to renew Kerberos TGTs
>      ldap_user_name = uid
>      krb5_renew_interval = 3600
>  # request renewable Kerberos tickets
>      krb5_renewable_lifetime = 30d
>      krb5_validate = False
>  
>  The machine is joined to MYDOMAIN1.COM (hence it has only credentials for this domain in
> the default krb5.keytab) - but since there is two way trust with MYDOMAIN2.com, it can use
> its machine Kerberos principal (granted from MYDOMAIN1)  for searches in both domains.
>  I tried that, it works well, but only in case I add:
>   "Ldap_sasl_authid = MYHOST$(a)MYDOMAIN1.COM" to the [domain/mydomain2] section.
Ah, I see. SSSD tries first to find a principal from the realm of the
domain. This fails for MYDOMAIN2.DOM because the principal is from
MYDOMAIN1.COM. Then SSSD falls back to allow principals from any realm.
But in this fall back there is no special case for the AD provider
anymore and SSSD pick the first entry which looks like 'host/anyname@ANYREALM'.

Would you mind to open a ticket on pagure to fix this?

Currently I cannot think of a good workaround. Instead of setting
ldap_sasl_authid you can create a second keytab for mydomain2 which only
contains the shortname$@MYDOMAIN1 entries of the original keytab. But it
would be hard to keep them in sync when keytab renewal is used. You
should not remove the 'host/..' entries from the default
/etc/krb5.keytab becasue e.g. sshd depends on them.

> 
> To me, this should not be necessary.
> Ondrej
> 
> 
> -----Original Message-----
> From: Sumit Bose [mailto:[e-mail]] 
> Sent: Tuesday, August 07, 2018 1:13 PM
> To: sssd-users(a)lists.fedorahosted.org
> Subject: [SSSD-users] Re: sssd connecting to two AD domains
> 
> On Mon, Aug 06, 2018 at 08:34:04AM +0000, Ondrej Valousek wrote:
> > Also, yes, setting ldap_sasl_authid does help, but it's bit awkward as right
now I am using general sssd.conf for all machines.
> > Having to include ldap_sasl_authid parameter means the configuration 
> > file is different for every machine :-(
> 
> Can you share your sssd.conf?
> 
> Are you using the AD or LDAP provider? Please note there are different defaults for
the principal for the two providers, AD will use “hostname$@REALM” while LDAP will use
“host/hostname@REALM”.
> 
> With two domains I'd always recommend to use two different keytab files and use
krb5_keytab and ldap_krb5_keytab to point at least one domain to the non-default keytab
file.
> 
> HTH
> 
> bye,
> Sumit
> 
> > Ondrej
> > 
> > -----Original Message-----
> > From: Ondrej Valousek [mailto:[e-mail]]
> > Sent: Monday, August 06, 2018 9:40 AM
> > To: End-user discussions about the System Security Services Daemon 
> > <sssd-users(a)lists.fedorahosted.org&gt;
> > Subject: [SSSD-users] Re: sssd connecting to two AD domains
> > 
> > Hi,
> > No, these are different forests, but a two way trust is established between
these two.
> > Ondrej
> > 
> > -----Original Message-----
> > From: Jakub Hrozek [mailto:[e-mail]]
> > Sent: Monday, August 06, 2018 9:36 AM
> > To: End-user discussions about the System Security Services Daemon 
> > <sssd-users(a)lists.fedorahosted.org&gt;
> > Subject: [SSSD-users] Re: sssd connecting to two AD domains
> > 
> > Are mydomain and mydomain2 coming from a different forest?
> > 
> > with id_provider=ad sssd should work fine with domains from the same forest and
it should pick the right principal. If it doesn’t and setting ldap_sasl_authid to
shortname$@realm, then there must be a bug in the principal selection logic.
> > 
> > > On 30 Jul 2018, at 11:25, Ondrej Valousek
<Ondrej.Valousek(a)s3group.com&gt; wrote:
> > > 
> > > Ok, I see that it’s probably not supported:
> > > https://pagure.io/SSSD/sssd/issue/2078
> > > right?
> > > Ondrej
> > >  
> > > From: Ondrej Valousek [mailto:[e-mail]]
> > > Sent: Monday, July 30, 2018 10:45 AM
> > > To: End-user discussions about the System Security Services Daemon 
> > > <sssd-users(a)lists.fedorahosted.org&gt;
> > > Subject: [SSSD-users] sssd connecting to two AD domains
> > >  
> > > Hi all,
> > >  
> > > I have a machine joined to AD domain “mydomain.com” and there is also
domain “mydomain2.com”. The two are connected with full two way trust.
> > >  
> > > SSSD can happily recognize users from “mydomain.com”, but fails with users
from “mydomain2.com” - sssd complains that:
> > >  
> > > (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000):
Port status of port 389 for server 'server.mydomain2.com' is 'not
working'
> > > (Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080):
SSSD is unable to complete the full connection request, this internal status does not
necessarily indicate network port issues.
> > >  
> > > But I can connect to that server with ldapsearch just fine (using a TGT
obtained with kinit –k hostname$).
> > >  
> > > Earlier in the logs I spotted that SSSD is trying to obtain TGT with a
wrong principal “host/hostname@REALM” instead of “hostname$@REALM”:
> > >  
> > >  
> > > (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv]
> > > (0x0400): Child responded: 14 [Client &#39;host/hostname(a)mydomain.COM&#39;

> > > not found in Kerberos database], expired on [0] (Mon Jul 30 08:32:34 
> > > 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get 
> > > TGT: 14 [Bad address] (Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] 
> > > [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret 
> > > [1432158226](Authentication Failed)
> > >  
> > >  
> > > I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using
wrong principal?
> > > Using RHEL-7.
> > > Thanks,
> > >  
> > > Ondrej
> > > -----
> > >  
> > > The information contained in this e-mail and in any attachments is
confidential and is designated solely for the attention of the intended recipient(s). If
you are not an intended recipient, you must not use, disclose, copy, distribute or retain
this e-mail or any part thereof. If you have received this e-mail in error, please notify
the sender by return e-mail and delete all copies of this e-mail from your computer
system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You.
Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18.
> > >  
> > > -----
> > > 
> > > The information contained in this e-mail and in any attachments is
confidential and is designated solely for the attention of the intended recipient(s). If
you are not an intended recipient, you must not use, disclose, copy, distribute or retain
this e-mail or any part thereof. If you have received this e-mail in error, please notify
the sender by return e-mail and delete all copies of this e-mail from your computer
system(s). Please direct any additional queries to: 
> > > communications(a)s3group.com. Thank You. Silicon and Software Systems Limited
(S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business
Park, Leopardstown, Dublin 18.
> > > _______________________________________________
> > > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
> > > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > > List Guidelines: 
> > > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives: 
> > > https://lists.fedoraproject.org/archives/list/[e-mail]
> > > ah osted.org/message/5AR2PPJ3ARQDVDTLPWPLN5PSB75HVO6V/
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > osted.org/message/Z6H27YNJRSOZE6735CWXMKAHAH4STNNG/
> > 
> > -----
> > 
> > The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > osted.org/message/UGEJ6IDFIDIVUJB3TC6CW7UTZ66WYMTZ/
> > 
> > -----
> > 
> > The information contained in this e-mail and in any attachments is confidential
and is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
> > _______________________________________________
> > sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To 
> > unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> > List Guidelines: 
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> > https://lists.fedoraproject.org/archives/list/[e-mail]
> > osted.org/message/7ZBUNYK6K7ZAVFEUTQXRO4ZTK6CFQSF7/
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org To unsubscribe send an
email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...
> 
> -----
> 
> The information contained in this e-mail and in any attachments is confidential and
is designated solely for the attention of the intended recipient(s). If you are not an
intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or
any part thereof. If you have received this e-mail in error, please notify the sender by
return e-mail and delete all copies of this e-mail from your computer system(s). Please
direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and
Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office:
South County Business Park, Leopardstown, Dublin 18.
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...