what are the causes of Port status of port 389 for server is 'not working'

[Jeremy Monnet]

Hi,

I have that error message that I do not understand, because I have 2 ubuntu
servers setup the same way (but 1 ubuntu 14.04 and 1 ubuntu 16.04). Ubuntu
14 is working fine, I can authenticate and sudo just fine, Ubuntu 16 can
list users and groups but I cannot authenticate nor sudo. And I see in the
sssd_domain.log :

(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'AD'
(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status] (0x1000):
Status of server '<servername>' is 'name resolved'
(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
Port status of port 389 for server '<servername>' is 'not working'
(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status] (0x1000):
Status of server '<servername2>' is 'name resolved'
(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
Port status of port 389 for server '<servername2>' is 'not working'
(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
(0x0020): No available servers for service 'AD'
(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [be_resolve_server_done]
(0x1000): Server resolution failed: 5
(Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [sdap_id_op_connect_done]
(0x0020): Failed to connect, going offline (5 [Input/output error])


Of course, port 389 is indeed reachable, and I have joined and re-joined
the domain several times, deleted the object computer in AD, checked
several times that the keytab was created, and that I could kinit with it...

One thing is that I join a child AD domain and tries to login with an
account from the main domain, that is probably an issue, but as that work
on the other Ubuntu with the same setup, I am stuck...

Thanks,

Jeremy

[Jakub Hrozek]

On Fri, Oct 20, 2017 at 04:39:54PM +0200, Jeremy Monnet wrote:
>  Hi,
>  
>  I have that error message that I do not understand, because I have 2 ubuntu
>  servers setup the same way (but 1 ubuntu 14.04 and 1 ubuntu 16.04). Ubuntu
>  14 is working fine, I can authenticate and sudo just fine, Ubuntu 16 can
>  list users and groups but I cannot authenticate nor sudo. And I see in the
>  sssd_domain.log :
>  
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
>  (0x0100): Trying to resolve service 'AD'
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status] (0x1000):
>  Status of server '<servername>' is 'name resolved'
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<servername>' is 'not working'
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status] (0x1000):
>  Status of server '<servername2>' is 'name resolved'
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<servername2>' is 'not
> working'
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
>  (0x0020): No available servers for service 'AD'
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [be_resolve_server_done]
>  (0x1000): Server resolution failed: 5
>  (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [sdap_id_op_connect_done]
>  (0x0020): Failed to connect, going offline (5 [Input/output error])
>  
>  
>  Of course, port 389 is indeed reachable, and I have joined and re-joined
>  the domain several times, deleted the object computer in AD, checked
>  several times that the keytab was created, and that I could kinit with it...
>  
>  One thing is that I join a child AD domain and tries to login with an
>  account from the main domain, that is probably an issue, but as that work
>  on the other Ubuntu with the same setup, I am stuck... 
Can you show the whole log or the first time the not working message
appeared since sssd restart?

[Jeremy Monnet]

Hi,



On Sat, Oct 21, 2017 at 8:56 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  On Fri, Oct 20, 2017 at 04:39:54PM +0200, Jeremy Monnet wrote:
>  > Hi,
>  >
>  > I have that error message that I do not understand, because I have 2
>  ubuntu
>  > servers setup the same way (but 1 ubuntu 14.04 and 1 ubuntu 16.04).
>  Ubuntu
>  > 14 is working fine, I can authenticate and sudo just fine, Ubuntu 16 can
>  > list users and groups but I cannot authenticate nor sudo. And I see in
>  the
>  > sssd_domain.log :
>  >
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
>  > (0x0100): Trying to resolve service 'AD'
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status]
>  (0x1000):
>  > Status of server '<servername>' is 'name resolved'
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
>  > Port status of port 389 for server '<servername>' is 'not
> working'
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status]
>  (0x1000):
>  > Status of server '<servername2>' is 'name resolved'
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
>  > Port status of port 389 for server '<servername2>' is 'not
> working'
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
>  > (0x0020): No available servers for service 'AD'
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [be_resolve_server_done]
>  > (0x1000): Server resolution failed: 5
>  > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [sdap_id_op_connect_done]
>  > (0x0020): Failed to connect, going offline (5 [Input/output error])
>  >
>  >
>  > Of course, port 389 is indeed reachable, and I have joined and re-joined
>  > the domain several times, deleted the object computer in AD, checked
>  > several times that the keytab was created, and that I could kinit with
>  it...
>  >
>  > One thing is that I join a child AD domain and tries to login with an
>  > account from the main domain, that is probably an issue, but as that work
>  > on the other Ubuntu with the same setup, I am stuck...
>
>  Can you show the whole log or the first time the not working message
>  appeared since sssd restart?
>
>  I have tried to sanitize the whole log file, but therareis too many 
acccounts,
servers, etc appearing in the logs, so I will try to provide you
just the required snippets. In parallel I will open a new thread because I
am not sure of the setup I use, and I haven't been to find the recommended
way of configuring an AD auth in real life (i.e. with multiple domains,
firewalls blocking the ports, etc...).

So I have restarted sssd this morning, clearing the logs in between, and I
get :
root@server:/var/log/sssd# grep "Port status of port" sssd_<domain>.log
(Mon Oct 23 09:37:28 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 0 for server '(no name)' is 'neutral'
(Mon Oct 23 09:37:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 0 for server '(no name)' is 'neutral'
(Mon Oct 23 09:37:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is
'working'
(Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 0 for server '(no name)' is 'neutral'
(Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is
'neutral'
(Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad1>.<domain>' is 'not
working'
(Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is 'not
working'
(Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad1>.<domain>' is 'not
working'
(Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is 'not
working'
(Mon Oct 23 09:39:20 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is
'working'
(Mon Oct 23 09:39:20 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is
'working'
(Mon Oct 23 09:39:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is
'working'
(Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad2>.<domain>' is
'neutral'
(Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad1>.<domain>' is
'working'
(Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad1>.<domain>' is
'working'
(Mon Oct 23 09:42:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 3268 for server '<ad1>.<domain>' is
'neutral'
(Mon Oct 23 09:42:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
Port status of port 389 for server '<ad1>.<domain>' is
'working'

In the attached snippet you will find all (Mon Oct 23 09:39:12 2017)

Thanks,

Jeremy

[Jakub Hrozek]

On Mon, Oct 23, 2017 at 10:11:50AM +0200, Jeremy Monnet wrote:
>  Hi,
>  
>  
>  
>  On Sat, Oct 21, 2017 at 8:56 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:
>  
>  > On Fri, Oct 20, 2017 at 04:39:54PM +0200, Jeremy Monnet wrote:
>  > > Hi,
>  > >
>  > > I have that error message that I do not understand, because I have 2
>  > ubuntu
>  > > servers setup the same way (but 1 ubuntu 14.04 and 1 ubuntu 16.04).
>  > Ubuntu
>  > > 14 is working fine, I can authenticate and sudo just fine, Ubuntu 16 can
>  > > list users and groups but I cannot authenticate nor sudo. And I see in
>  > the
>  > > sssd_domain.log :
>  > >
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
>  > > (0x0100): Trying to resolve service 'AD'
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status]
>  > (0x1000):
>  > > Status of server '<servername>' is 'name resolved'
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
>  > > Port status of port 389 for server '<servername>' is 'not
> working'
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status]
>  > (0x1000):
>  > > Status of server '<servername2>' is 'name resolved'
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status] (0x1000):
>  > > Port status of port 389 for server '<servername2>' is 'not
> working'
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [fo_resolve_service_send]
>  > > (0x0020): No available servers for service 'AD'
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [be_resolve_server_done]
>  > > (0x1000): Server resolution failed: 5
>  > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [sdap_id_op_connect_done]
>  > > (0x0020): Failed to connect, going offline (5 [Input/output error])
>  > >
>  > >
>  > > Of course, port 389 is indeed reachable, and I have joined and re-joined
>  > > the domain several times, deleted the object computer in AD, checked
>  > > several times that the keytab was created, and that I could kinit with
>  > it...
>  > >
>  > > One thing is that I join a child AD domain and tries to login with an
>  > > account from the main domain, that is probably an issue, but as that work
>  > > on the other Ubuntu with the same setup, I am stuck...
>  >
>  > Can you show the whole log or the first time the not working message
>  > appeared since sssd restart?
>  >
>  > I have tried to sanitize the whole log file, but therareis too many
>  acccounts, servers, etc appearing in the logs, so I will try to provide you
>  just the required snippets. In parallel I will open a new thread because I
>  am not sure of the setup I use, and I haven't been to find the recommended
>  way of configuring an AD auth in real life (i.e. with multiple domains,
>  firewalls blocking the ports, etc...).
>  
>  So I have restarted sssd this morning, clearing the logs in between, and I
>  get :
>  root@server:/var/log/sssd# grep "Port status of port" sssd_<domain>.log
>  (Mon Oct 23 09:37:28 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 0 for server '(no name)' is 'neutral'
>  (Mon Oct 23 09:37:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 0 for server '(no name)' is 'neutral'
>  (Mon Oct 23 09:37:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 0 for server '(no name)' is 'neutral'
>  (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is
> 'neutral'
>  (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad1>.<domain>' is 'not
> working'
>  (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is 'not
> working'
>  (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad1>.<domain>' is 'not
> working'
>  (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is 'not
> working'
>  (Mon Oct 23 09:39:20 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  (Mon Oct 23 09:39:20 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  (Mon Oct 23 09:39:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  (Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad2>.<domain>' is
> 'neutral'
>  (Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad1>.<domain>' is
> 'working'
>  (Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad1>.<domain>' is
> 'working'
>  (Mon Oct 23 09:42:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 3268 for server '<ad1>.<domain>' is
> 'neutral'
>  (Mon Oct 23 09:42:38 2017) [sssd[be[<domain>]]] [get_port_status] (0x1000):
>  Port status of port 389 for server '<ad1>.<domain>' is
> 'working'
>  
>  In the attached snippet you will find all (Mon Oct 23 09:39:12 2017) 
This sounds wrong:
     [sdap_kinit_send] (0x0400): Attempting kinit (default,
host/<servername>.<subdomain>.<domain>,
<SUBDOMAIN>.<DOMAIN>, 86400)
with AD, you normally want to use the SHORTNAME$REALM principal, not the
host/hostname principal, because the latter is only a service principal,
not a user/computer one.

But since you're using id_provider=ad, then sssd should have already picked
up that principal..is the SHORTNAME$@REALM principal in your keytab at all?

[Jeremy Monnet]

On Mon, Oct 23, 2017 at 3:29 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  On Mon, Oct 23, 2017 at 10:11:50AM +0200, Jeremy Monnet wrote:
>  > Hi,
>  >
>  >
>  >
>  > On Sat, Oct 21, 2017 at 8:56 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt;
>  wrote:
>  >
>  > > On Fri, Oct 20, 2017 at 04:39:54PM +0200, Jeremy Monnet wrote:
>  > > > Hi,
>  > > >
>  > > > I have that error message that I do not understand, because I have 2
>  > > ubuntu
>  > > > servers setup the same way (but 1 ubuntu 14.04 and 1 ubuntu 16.04).
>  > > Ubuntu
>  > > > 14 is working fine, I can authenticate and sudo just fine, Ubuntu 16
>  can
>  > > > list users and groups but I cannot authenticate nor sudo. And I see
>  in
>  > > the
>  > > > sssd_domain.log :
>  > > >
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]]
>  [fo_resolve_service_send]
>  > > > (0x0100): Trying to resolve service 'AD'
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status]
>  > > (0x1000):
>  > > > Status of server '<servername>' is 'name resolved'
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status]
>  (0x1000):
>  > > > Port status of port 389 for server '<servername>' is
> 'not working'
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_server_status]
>  > > (0x1000):
>  > > > Status of server '<servername2>' is 'name resolved'
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]] [get_port_status]
>  (0x1000):
>  > > > Port status of port 389 for server '<servername2>' is
> 'not working'
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]]
>  [fo_resolve_service_send]
>  > > > (0x0020): No available servers for service 'AD'
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]]
>  [be_resolve_server_done]
>  > > > (0x1000): Server resolution failed: 5
>  > > > (Fri Oct 20 16:27:29 2017) [sssd[be[domain]]]
>  [sdap_id_op_connect_done]
>  > > > (0x0020): Failed to connect, going offline (5 [Input/output error])
>  > > >
>  > > >
>  > > > Of course, port 389 is indeed reachable, and I have joined and
>  re-joined
>  > > > the domain several times, deleted the object computer in AD, checked
>  > > > several times that the keytab was created, and that I could kinit
>  with
>  > > it...
>  > > >
>  > > > One thing is that I join a child AD domain and tries to login with an
>  > > > account from the main domain, that is probably an issue, but as that
>  work
>  > > > on the other Ubuntu with the same setup, I am stuck...
>  > >
>  > > Can you show the whole log or the first time the not working message
>  > > appeared since sssd restart?
>  > >
>  > > I have tried to sanitize the whole log file, but therareis too many
>  > acccounts, servers, etc appearing in the logs, so I will try to provide
>  you
>  > just the required snippets. In parallel I will open a new thread because
>  I
>  > am not sure of the setup I use, and I haven't been to find the
>  recommended
>  > way of configuring an AD auth in real life (i.e. with multiple domains,
>  > firewalls blocking the ports, etc...).
>  >
>  > So I have restarted sssd this morning, clearing the logs in between, and
>  I
>  > get :
>  > root@server:/var/log/sssd# grep "Port status of port"
> sssd_<domain>.log
>  > (Mon Oct 23 09:37:28 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 0 for server '(no name)' is 'neutral'
>  > (Mon Oct 23 09:37:38 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 0 for server '(no name)' is 'neutral'
>  > (Mon Oct 23 09:37:38 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  > (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 0 for server '(no name)' is 'neutral'
>  > (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is
> 'neutral'
>  > (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad1>.<domain>' is 'not
> working'
>  > (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is 'not
> working'
>  > (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad1>.<domain>' is 'not
> working'
>  > (Mon Oct 23 09:39:12 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is 'not
> working'
>  > (Mon Oct 23 09:39:20 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  > (Mon Oct 23 09:39:20 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  > (Mon Oct 23 09:39:31 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is
> 'working'
>  > (Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad2>.<domain>' is
> 'neutral'
>  > (Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad1>.<domain>' is
> 'working'
>  > (Mon Oct 23 09:40:31 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad1>.<domain>' is
> 'working'
>  > (Mon Oct 23 09:42:38 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 3268 for server '<ad1>.<domain>' is
> 'neutral'
>  > (Mon Oct 23 09:42:38 2017) [sssd[be[<domain>]]] [get_port_status]
>  (0x1000):
>  > Port status of port 389 for server '<ad1>.<domain>' is
> 'working'
>  >
>  > In the attached snippet you will find all (Mon Oct 23 09:39:12 2017)
>
>  This sounds wrong:
>       [sdap_kinit_send] (0x0400): Attempting kinit (default,
>  host/<servername>.<subdomain>.<domain>,
> <SUBDOMAIN>.<DOMAIN>, 86400)
>  with AD, you normally want to use the SHORTNAME$REALM principal, not the
>  host/hostname principal, because the latter is only a service principal,
>  not a user/computer one.
>
>  But since you're using id_provider=ad, then sssd should have already picked
>  up that principal..is the SHORTNAME$@REALM principal in your keytab at all?
>  
Yes, it is

root@servername:~# klist -k
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
----
--------------------------------------------------------------------------
   2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
   2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
   2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
   2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
   2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
   2 host/servername(a)SUB1.EXAMPLE.COM
   2 host/servername(a)SUB1.EXAMPLE.COM
   2 host/servername(a)SUB1.EXAMPLE.COM
   2 host/servername(a)SUB1.EXAMPLE.COM
   2 host/servername(a)SUB1.EXAMPLE.COM
   2 SERVERNAME$(a)SUB1.EXAMPLE.COM
   2 SERVERNAME$(a)SUB1.EXAMPLE.COM
   2 SERVERNAME$(a)SUB1.EXAMPLE.COM
   2 SERVERNAME$(a)SUB1.EXAMPLE.COM
   2 SERVERNAME$(a)SUB1.EXAMPLE.COM

Jeremy

[Jeremy Monnet]

On Mon, Oct 23, 2017 at 4:55 PM, Jeremy Monnet <jmonnet(a)gmail.com&gt; wrote:

> > This sounds wrong:
> >      [sdap_kinit_send] (0x0400): Attempting kinit (default,
> > host/<servername>.<subdomain>.<domain>,
> <SUBDOMAIN>.<DOMAIN>, 86400)
> > with AD, you normally want to use the SHORTNAME$REALM principal, not the
> > host/hostname principal, because the latter is only a service principal,
> > not a user/computer one.
> >
> > But since you're using id_provider=ad, then sssd should have already
> > picked
> > up that principal..is the SHORTNAME$@REALM principal in your keytab at
> > all?
> >
>  Yes, it is
>
>  root@servername:~# klist -k
>  Keytab name: FILE:/etc/krb5.keytab
>  KVNO Principal
>  ---- ------------------------------------------------------------
>  --------------
>     2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>     2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>     2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>     2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>     2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>     2 host/servername(a)SUB1.EXAMPLE.COM
>     2 host/servername(a)SUB1.EXAMPLE.COM
>     2 host/servername(a)SUB1.EXAMPLE.COM
>     2 host/servername(a)SUB1.EXAMPLE.COM
>     2 host/servername(a)SUB1.EXAMPLE.COM
>     2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>     2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>     2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>     2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>     2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>
>
>  Some more information (in case that would help...) 
1 AD forest with multiple domains : example.com and sub1.example.com
2 users : my_user(a)example.com, testuser(a)sub1.example.com
2 servers setup the same way (same adcli commands to get the krb5.keytab,
same resolv.conf/hosts/sssd.conf etc), but 1 is ubuntu 14 with
sssd 1.11.8-0ubunt, 1 is ubuntu 16 with sssd 1.13.4-1ubunt

(BTW I have about 15 other linuces (RHEL6/RHEL7/ubuntu14) that are
connected only to example.com and working OK. Only these 2 servers are
members of sub1.example.com with a need to authenticate also users from
example.com)

On these 2 servers, authentication works for testuser(a)sub1.example.com. I
can authenticate with my_user(a)example.com on the ubuntu 14 with sssd
1.11.But I cannot authenticate with my_user(a)example.com on the ubuntu 16
with sssd 1.13.

sssd.conf for both servers :
[sssd]
config_file_version = 2
debug_level =0
domains = sub1.example.com,example.com
services = nss, pam

[domain/example.com]
enumerate = true
dns_discovery_domain = cy2._sites.example.com
debug_level = 9
id_provider = ad
access_provider = ad
ldap_id_mapping = false

[domain/sub1.example.com]
enumerate = true
dns_discovery_domain = cy2._sites.sub1.example.com
debug_level = 7
id_provider = ad
access_provider = ad
ldap_id_mapping = false

I have played with ad_hostname, ldap_sasl_authid, ldap_sasl_realm with
little succes (I am not even sure ldap_sasl_* variables are useful with
id_provider =ad...)

There is only one tiny difference I see in the SPN's : my ubuntu 16 is the
only of my servers that has a host/SERVERNAME SPN, all the others have
HOST/SERVERNAME (Capital HOST). I cannot not understand though why that
would allow the auth to the subdomain but not to the main, but I know
kerberos is very sensible to the case, so just in case. And anyway, that is
coherent with the keytab.

Thanks,

Jeremy

[Jakub Hrozek]

On Mon, Oct 23, 2017 at 06:47:53PM +0200, Jeremy Monnet wrote:
>  On Mon, Oct 23, 2017 at 4:55 PM, Jeremy Monnet
> <jmonnet(a)gmail.com&gt; wrote:
>  
>  >
>  >> This sounds wrong:
>  >>      [sdap_kinit_send] (0x0400): Attempting kinit (default,
>  >> host/<servername>.<subdomain>.<domain>,
> <SUBDOMAIN>.<DOMAIN>, 86400)
>  >> with AD, you normally want to use the SHORTNAME$REALM principal, not the
>  >> host/hostname principal, because the latter is only a service principal,
>  >> not a user/computer one.
>  >>
>  >> But since you're using id_provider=ad, then sssd should have already
>  >> picked
>  >> up that principal..is the SHORTNAME$@REALM principal in your keytab at
>  >> all?
>  >>
>  > Yes, it is
>  >
>  > root@servername:~# klist -k
>  > Keytab name: FILE:/etc/krb5.keytab
>  > KVNO Principal
>  > ---- ------------------------------------------------------------
>  > --------------
>  >    2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>  >    2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>  >    2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>  >    2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>  >    2 host/servername.sub1.example.com(a)SUB1.EXAMPLE.COM
>  >    2 host/servername(a)SUB1.EXAMPLE.COM
>  >    2 host/servername(a)SUB1.EXAMPLE.COM
>  >    2 host/servername(a)SUB1.EXAMPLE.COM
>  >    2 host/servername(a)SUB1.EXAMPLE.COM
>  >    2 host/servername(a)SUB1.EXAMPLE.COM
>  >    2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>  >    2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>  >    2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>  >    2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>  >    2 SERVERNAME$(a)SUB1.EXAMPLE.COM
>  >
>  >
>  > Some more information (in case that would help...)
>  
>  1 AD forest with multiple domains : example.com and sub1.example.com
>  2 users : my_user(a)example.com, testuser(a)sub1.example.com
>  2 servers setup the same way (same adcli commands to get the krb5.keytab,
>  same resolv.conf/hosts/sssd.conf etc), but 1 is ubuntu 14 with
>  sssd 1.11.8-0ubunt, 1 is ubuntu 16 with sssd 1.13.4-1ubunt
>  
>  (BTW I have about 15 other linuces (RHEL6/RHEL7/ubuntu14) that are
>  connected only to example.com and working OK. Only these 2 servers are
>  members of sub1.example.com with a need to authenticate also users from
>  example.com)
>  
>  On these 2 servers, authentication works for testuser(a)sub1.example.com. I
>  can authenticate with my_user(a)example.com on the ubuntu 14 with sssd
>  1.11.But I cannot authenticate with my_user(a)example.com on the ubuntu 16
>  with sssd 1.13. 
This is quite a new version, which already supports discovering trusted
domains in the same forest, so defining the root domain (example.com)
shouldn't be even required. The subdomain provider (which defaults to "ad",
same as the id_provider's value) should discover example.com on its own.

(Actually, with your setup, I would even think the explicitly defined
example.com domain is ignored at sssd would query the autodiscovered
subdomain of sub1.example.com if you ask it for any entry from example.com)

>  
>  sssd.conf for both servers :
>  [sssd]
>  config_file_version = 2
>  debug_level =0
>  domains = sub1.example.com,example.com
>  services = nss, pam
>  
>  [domain/example.com]
>  enumerate = true
>  dns_discovery_domain = cy2._sites.example.com
>  debug_level = 9
>  id_provider = ad
>  access_provider = ad
>  ldap_id_mapping = false
>  
>  [domain/sub1.example.com]
>  enumerate = true
>  dns_discovery_domain = cy2._sites.sub1.example.com 
It's easier to use:
	ad_site = cy2
with a recent version. But I guess this won't work with 1.11..

>  debug_level = 7
>  id_provider = ad
>  access_provider = ad
>  ldap_id_mapping = false
>  
>  I have played with ad_hostname, ldap_sasl_authid, ldap_sasl_realm with
>  little succes (I am not even sure ldap_sasl_* variables are useful with
>  id_provider =ad...)
>  
>  There is only one tiny difference I see in the SPN's : my ubuntu 16 is the
>  only of my servers that has a host/SERVERNAME SPN, all the others have
>  HOST/SERVERNAME (Capital HOST). I cannot not understand though why that
>  would allow the auth to the subdomain but not to the main, but I know
>  kerberos is very sensible to the case, so just in case. And anyway, that is
>  coherent with the keytab. 
First, sssd should not select the host/hostname principal to connect to
AD LDAP, but it should use the SHORTNAME$@REALM principal. You can search
for messages from "select_principal_from_keytab" to see what principal did
SSSD match, for example this is how my setup looks like:

(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [sdap_set_sasl_options] (0x0100):
Will look for adclient.win.trust.test(a)WIN.TRUST.TEST in default keytab
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [select_principal_from_keytab]
(0x0200): trying to select the most appropriate principal from keytab
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [find_principal_in_keytab] (0x4000):
Trying to find principal adclient.win.trust.test(a)WIN.TRUST.TEST in keytab.
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [find_principal_in_keytab] (0x0400):
No principal matching adclient.win.trust.test(a)WIN.TRUST.TEST found in keytab.
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [find_principal_in_keytab] (0x4000):
Trying to find principal ADCLIENT$(a)WIN.TRUST.TEST in keytab.
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [match_principal] (0x1000):
Principal matched to the sample (ADCLIENT$(a)WIN.TRUST.TEST).
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [select_principal_from_keytab]
(0x0200): Selected primary: ADCLIENT$
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [select_principal_from_keytab]
(0x0200): Selected realm: WIN.TRUST.TEST
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [sdap_set_sasl_options] (0x0100):
Option ldap_sasl_authid set to ADCLIENT$
(Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [sdap_set_sasl_options] (0x0100):
Option ldap_sasl_realm set to WIN.TRUST.TEST

I would also discourage enumerate=True, currently the performance is not
the best with large domains..

So all in all, I would check which principal does sssd choose..trimming
the config file by disabling the root domain and disabling enumeration
might help as well, at least as far as log files readability goes.

[Jeremy Monnet]

Hi,

On Tue, Oct 24, 2017 at 10:03 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:

>  >
>  > On these 2 servers, authentication works for testuser(a)sub1.example.com.
>  I
>  > can authenticate with my_user(a)example.com on the ubuntu 14 with sssd
>  > 1.11.But I cannot authenticate with my_user(a)example.com on the ubuntu 16
>  > with sssd 1.13.
>
>  This is quite a new version, which already supports discovering trusted
>  domains in the same forest, so defining the root domain (example.com)
>  shouldn't be even required. The subdomain provider (which defaults to
> "ad",
>  same as the id_provider's value) should discover example.com on its own.
>  
Hum, not quite :

root@<servername>:~# id my_user
uid=10000(my_user) gid=10001(ggs_admin_linux)
groups=10001(ggs_admin_linux),10006(ggs_sa
mba_logs),10002(ggs_samba_users)
root@<servername>:~# id test_user
uid=11400(test_user) gid=11400(test_group) groups=11400(test_group)

In between, I comment the main domain
root@<servername>:~# grep -v "^$\|^#" /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
debug_level =0
domains = sub1.example.com
services = nss, pam
[domain/sub1.example.com]
dns_discovery_domain = cy2._sites.sub1.example.com
ad_server = ad1.sub1.example.com,ad2.sub1.example.com
debug_level = 7
id_provider = ad
access_provider = ad
ldap_id_mapping = false


root@<servername>:~# id my_user
id: ‘my_user’: no such user
root@<servername>:~# id test_user
uid=11400(test_user) gid=11400(test_group) groups=11400(test_group)
root@<servername>:~# id my_user(a)example.com
uid=10000(my_user(a)example.com) gid=10001 groups=10001

my_user (without domain specification) is not found as it does not belong
to the subdomain, and the groups are not resolved to their names anymore.
It is possible (I am no expert on that matter) that without posix
attributes it would be easier, as it would search through the domain for
SID's...


>  (Actually, with your setup, I would even think the explicitly defined
>  example.com domain is ignored at sssd would query the autodiscovered
>  subdomain of sub1.example.com if you ask it for any entry from example.com
>  )
>  
Well it seems it is not ignored :-)


>  It's easier to use:
>          ad_site = cy2
>  with a recent version. But I guess this won't work with 1.11..
>  
I take note for when we will be only with recent OS's ;-)


>  > debug_level = 7
>  > id_provider = ad
>  > access_provider = ad
>  > ldap_id_mapping = false
>  >
>  > I have played with ad_hostname, ldap_sasl_authid, ldap_sasl_realm with
>  > little succes (I am not even sure ldap_sasl_* variables are useful with
>  > id_provider =ad...)
>  >
>  > There is only one tiny difference I see in the SPN's : my ubuntu 16 is
>  the
>  > only of my servers that has a host/SERVERNAME SPN, all the others have
>  > HOST/SERVERNAME (Capital HOST). I cannot not understand though why that
>  > would allow the auth to the subdomain but not to the main, but I know
>  > kerberos is very sensible to the case, so just in case. And anyway, that
>  is
>  > coherent with the keytab.
>
>  First, sssd should not select the host/hostname principal to connect to
>  AD LDAP, but it should use the SHORTNAME$@REALM principal. You can search
>  for messages from "select_principal_from_keytab" to see what principal did
>  SSSD match, for example this is how my setup looks like:
>
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [sdap_set_sasl_options] (0x0100): Will look for adclient.win.trust.test(a)WIN.TRUST.TEST
>  in default keytab
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [select_principal_from_keytab] (0x0200): trying to select the most
>  appropriate principal from keytab
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [find_principal_in_keytab] (0x4000): Trying to find principal
>  adclient.win.trust.test(a)WIN.TRUST.TEST in keytab.
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [find_principal_in_keytab] (0x0400): No principal matching
>  adclient.win.trust.test(a)WIN.TRUST.TEST found in keytab.
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [find_principal_in_keytab] (0x4000): Trying to find principal
>  ADCLIENT$(a)WIN.TRUST.TEST in keytab.
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [match_principal]
>  (0x1000): Principal matched to the sample (ADCLIENT$(a)WIN.TRUST.TEST).
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [select_principal_from_keytab] (0x0200): Selected primary: ADCLIENT$
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [select_principal_from_keytab] (0x0200): Selected realm: WIN.TRUST.TEST
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [sdap_set_sasl_options] (0x0100): Option ldap_sasl_authid set to ADCLIENT$
>  (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  [sdap_set_sasl_options] (0x0100): Option ldap_sasl_realm set to
>  WIN.TRUST.TEST 

sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [select_principal_from_keytab] (0x0200): trying to
select the most appropriate principal from keytab
sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
primary: SERVERNAME$
sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
realm: SUB1.EXAMPLE.COM
sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [select_principal_from_keytab] (0x0200): trying to
select the most appropriate principal from keytab
sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
primary: SERVERNAME$
sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
realm: SUB1.EXAMPLE.COM
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): trying to select the most
appropriate principal from keytab
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): Selected primary: host/SERVERNAME
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): Selected realm: SUB1.EXAMPLE.COM
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): trying to select the most
appropriate principal from keytab
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): Selected primary: host/SERVERNAME
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): Selected realm: SUB1.EXAMPLE.COM
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): trying to select the most
appropriate principal from keytab
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): Selected primary: host/SERVERNAME
sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
[select_principal_from_keytab] (0x0200): Selected realm: SUB1.EXAMPLE.COM


sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [match_principal] (0x1000): Principal matched to the
sample (SERVERNAME$(a)SUB1.EXAMPLE.COM).
sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
sub1.example.com]]] [match_principal] (0x1000): Principal matched to the
sample (SERVERNAME$(a)SUB1.EXAMPLE.COM).
sssd_example.com.log.1:(Mon Oct 23 09:37:28 2017) [sssd[be[example.com]]]
[match_principal] (0x1000): Principal matched to the sample (SERVERNAME$@
SUB1.EXAMPLE.COM).
sssd_example.com.log.1:(Mon Oct 23 09:37:28 2017) [sssd[be[example.com]]]
[match_principal] (0x1000): Principal matched to the sample (host/*@(null)).
sssd_example.com.log.1:(Mon Oct 23 09:37:28 2017) [sssd[be[example.com]]]
[match_principal] (0x1000): Principal matched to the sample (host/*@(null)).
sssd_example.com.log.1:(Mon Oct 23 14:41:10 2017) [sssd[be[example.com]]]
[match_principal] (0x1000): Principal matched to the sample (SERVERNAME$@
SUB1.EXAMPLE.COM).
sssd_example.com.log.1:(Mon Oct 23 14:41:10 2017) [sssd[be[example.com]]]
[match_principal] (0x1000): Principal matched to the sample (host/*@(null)).

>  
I would also discourage enumerate=True, currently the performance is not
> the best with large domains..
>  
I did it, even if we have a small AD, so performance is not the issue here.


> So all in all, I would check which principal does sssd choose..trimming
> the config file by disabling the root domain and disabling enumeration
> might help as well, at least as far as log files readability goes.
> _______________________________________________
>  
And this is what I get for 3 authentication tries
Oct 25 15:36:42 servername sshd[9487]: pam_unix(sshd:auth): check pass;
user unknown
Oct 25 15:36:42 servername sshd[9487]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.35.22
Oct 25 15:36:42 servername sshd[9487]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.35.22
user=my_user
Oct 25 15:36:42 servername sshd[9487]: pam_sss(sshd:auth): received for
user my_user: 10 (User not known to the underlying authentication module)

Oct 25 15:37:25 servername sshd[9595]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.35.22
user=test_user
Oct 25 15:37:25 servername sshd[9595]: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.35.22
user=test_user
Oct 25 15:37:25 servername sshd[9595]: pam_unix(sshd:session): session
opened for user test_user by (uid=0)
Oct 25 15:37:25 servername systemd: pam_unix(systemd-user:session): session
opened for user test_user by (uid=0)

Oct 25 15:38:25 servername sshd[9768]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.35.22  user=
my_user(a)example.com
Oct 25 15:38:25 servername sshd[9768]: pam_sss(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.20.35.22 user=
my_user(a)example.com
Oct 25 15:38:25 servername sshd[9768]: pam_sss(sshd:auth): received for
user my_user(a)example.com: 9 (Authentication service cannot retrieve
authentication info)

Jeremy

[Jakub Hrozek]

On Wed, Oct 25, 2017 at 03:43:14PM +0200, Jeremy Monnet wrote:
>  Hi,
>  
>  On Tue, Oct 24, 2017 at 10:03 PM, Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote:
>  
>  > >
>  > > On these 2 servers, authentication works for testuser(a)sub1.example.com.
>  > I
>  > > can authenticate with my_user(a)example.com on the ubuntu 14 with sssd
>  > > 1.11.But I cannot authenticate with my_user(a)example.com on the ubuntu 16
>  > > with sssd 1.13.
>  >
>  > This is quite a new version, which already supports discovering trusted
>  > domains in the same forest, so defining the root domain (example.com)
>  > shouldn't be even required. The subdomain provider (which defaults to
> "ad",
>  > same as the id_provider's value) should discover example.com on its own.
>  >
>  
>  Hum, not quite :
>  
>  root@<servername>:~# id my_user
>  uid=10000(my_user) gid=10001(ggs_admin_linux)
>  groups=10001(ggs_admin_linux),10006(ggs_sa
>  mba_logs),10002(ggs_samba_users)
>  root@<servername>:~# id test_user
>  uid=11400(test_user) gid=11400(test_group) groups=11400(test_group)
>  
>  In between, I comment the main domain
>  root@<servername>:~# grep -v "^$\|^#" /etc/sssd/sssd.conf
>  [sssd]
>  config_file_version = 2
>  debug_level =0
>  domains = sub1.example.com
>  services = nss, pam
>  [domain/sub1.example.com]
>  dns_discovery_domain = cy2._sites.sub1.example.com
>  ad_server = ad1.sub1.example.com,ad2.sub1.example.com
>  debug_level = 7
>  id_provider = ad
>  access_provider = ad
>  ldap_id_mapping = false
>  
>  
>  root@<servername>:~# id my_user
>  id: ‘my_user’: no such user
>  root@<servername>:~# id test_user
>  uid=11400(test_user) gid=11400(test_group) groups=11400(test_group)
>  root@<servername>:~# id my_user(a)example.com
>  uid=10000(my_user(a)example.com) gid=10001 groups=10001
>  
>  my_user (without domain specification) is not found as it does not belong
>  to the subdomain, and the groups are not resolved to their names anymore.
>  It is possible (I am no expert on that matter) that without posix
>  attributes it would be easier, as it would search through the domain for
>  SID's...
>  
>  
>  >
>  > (Actually, with your setup, I would even think the explicitly defined
>  > example.com domain is ignored at sssd would query the autodiscovered
>  > subdomain of sub1.example.com if you ask it for any entry from example.com
>  > )
>  >
>  
>  Well it seems it is not ignored :-)
>  
>  
>  >
>  >
>  > It's easier to use:
>  >         ad_site = cy2
>  > with a recent version. But I guess this won't work with 1.11..
>  >
>  
>  I take note for when we will be only with recent OS's ;-)
>  
>  
>  >
>  > > debug_level = 7
>  > > id_provider = ad
>  > > access_provider = ad
>  > > ldap_id_mapping = false
>  > >
>  > > I have played with ad_hostname, ldap_sasl_authid, ldap_sasl_realm with
>  > > little succes (I am not even sure ldap_sasl_* variables are useful with
>  > > id_provider =ad...)
>  > >
>  > > There is only one tiny difference I see in the SPN's : my ubuntu 16 is
>  > the
>  > > only of my servers that has a host/SERVERNAME SPN, all the others have
>  > > HOST/SERVERNAME (Capital HOST). I cannot not understand though why that
>  > > would allow the auth to the subdomain but not to the main, but I know
>  > > kerberos is very sensible to the case, so just in case. And anyway, that
>  > is
>  > > coherent with the keytab.
>  >
>  > First, sssd should not select the host/hostname principal to connect to
>  > AD LDAP, but it should use the SHORTNAME$@REALM principal. You can search
>  > for messages from "select_principal_from_keytab" to see what principal
> did
>  > SSSD match, for example this is how my setup looks like:
>  >
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [sdap_set_sasl_options] (0x0100): Will look for
> adclient.win.trust.test(a)WIN.TRUST.TEST
>  > in default keytab
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [select_principal_from_keytab] (0x0200): trying to select the most
>  > appropriate principal from keytab
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [find_principal_in_keytab] (0x4000): Trying to find principal
>  > adclient.win.trust.test(a)WIN.TRUST.TEST in keytab.
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [find_principal_in_keytab] (0x0400): No principal matching
>  > adclient.win.trust.test(a)WIN.TRUST.TEST found in keytab.
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [find_principal_in_keytab] (0x4000): Trying to find principal
>  > ADCLIENT$(a)WIN.TRUST.TEST in keytab.
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]] [match_principal]
>  > (0x1000): Principal matched to the sample (ADCLIENT$(a)WIN.TRUST.TEST).
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [select_principal_from_keytab] (0x0200): Selected primary: ADCLIENT$
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [select_principal_from_keytab] (0x0200): Selected realm: WIN.TRUST.TEST
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [sdap_set_sasl_options] (0x0100): Option ldap_sasl_authid set to ADCLIENT$
>  > (Tue Oct 24 19:58:20 2017) [sssd[be[win.trust.test]]]
>  > [sdap_set_sasl_options] (0x0100): Option ldap_sasl_realm set to
>  > WIN.TRUST.TEST
>  
>  
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [select_principal_from_keytab] (0x0200): trying to
>  select the most appropriate principal from keytab
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
>  primary: SERVERNAME$
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
>  realm: SUB1.EXAMPLE.COM
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [select_principal_from_keytab] (0x0200): trying to
>  select the most appropriate principal from keytab
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
>  primary: SERVERNAME$
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [select_principal_from_keytab] (0x0200): Selected
>  realm: SUB1.EXAMPLE.COM
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): trying to select the most
>  appropriate principal from keytab
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): Selected primary: host/SERVERNAME
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): Selected realm: SUB1.EXAMPLE.COM
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): trying to select the most
>  appropriate principal from keytab
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): Selected primary: host/SERVERNAME
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): Selected realm: SUB1.EXAMPLE.COM
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): trying to select the most
>  appropriate principal from keytab
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): Selected primary: host/SERVERNAME
>  sssd_example.com.log.1:(Mon Oct 23 18:17:09 2017) [sssd[be[example.com]]]
>  [select_principal_from_keytab] (0x0200): Selected realm: SUB1.EXAMPLE.COM
>  
>  
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [match_principal] (0x1000): Principal matched to the
>  sample (SERVERNAME$(a)SUB1.EXAMPLE.COM).
>  sssd_sub1.example.com.log:(Wed Oct 25 15:06:40 2017) [sssd[be[
>  sub1.example.com]]] [match_principal] (0x1000): Principal matched to the
>  sample (SERVERNAME$(a)SUB1.EXAMPLE.COM). 
OK, here the principal matched to what I'd expect.

>  sssd_example.com.log.1:(Mon Oct 23 09:37:28 2017)
> [sssd[be[example.com]]]
>  [match_principal] (0x1000): Principal matched to the sample (SERVERNAME$@
>  SUB1.EXAMPLE.COM).
>  sssd_example.com.log.1:(Mon Oct 23 09:37:28 2017) [sssd[be[example.com]]]
>  [match_principal] (0x1000): Principal matched to the sample (host/*@(null)).
>  sssd_example.com.log.1:(Mon Oct 23 09:37:28 2017) [sssd[be[example.com]]]
>  [match_principal] (0x1000): Principal matched to the sample (host/*@(null)).
>  sssd_example.com.log.1:(Mon Oct 23 14:41:10 2017) [sssd[be[example.com]]]
>  [match_principal] (0x1000): Principal matched to the sample (SERVERNAME$@
>  SUB1.EXAMPLE.COM).
>  sssd_example.com.log.1:(Mon Oct 23 14:41:10 2017) [sssd[be[example.com]]]
>  [match_principal] (0x1000): Principal matched to the sample (host/*@(null)). 
But here to a different pattern and I don't think the host/ principal will work
with AD.

Can you try adding:
    ldap_sasl_authid = SERVERNAME$(a)SUB1.EXAMPLE.COM
to the example.com section?