[Samba] Opensolaris-ish joins but does not seem to be valid

[Rowland Penny]

On Thu, 12 Oct 2017 13:28:40 -0500 (CDT)
Mike Ray <mray at xes-inc.com> wrote:

> ----- On Oct 11, 2017, at 5:56 PM, samba samba at lists.samba.org wrote:
> 
> > ----- On Oct 10, 2017, at 12:02 PM, samba samba at lists.samba.org
> > wrote:
> > 
> >> On Tue, 10 Oct 2017 11:28:09 -0500 (CDT)
> >> Andrew Martin <amartin at xes-inc.com> wrote:
> >> 
> >> 
> > 
> > Rowland-
> > 
> > I've been poking at this more and think the root of the problem is
> > a Kerberos problem.
> > 
> 
> 
> I threw the log level up to 10 in /etc/smb.conf on the domain
> controller and poked around more.
> 
> Below are some pieces of the log:
> 
> 
> 
> 
> 
>   Kerberos: AS-REQ root/hostname.example.com at EXAMPLE.COM from
> ipv4:192.168.0.115:41751 for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at EXAMPLE.COM))
> expr: (&(objectClass=user)(samAccountName=root/hostname.example.com))
> expr:
> (&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
> servicePrincipalName: host/hostname.example.com servicePrincipalName:
> nfs/hostname.example.com servicePrincipalName:
> HTTP/hostname.example.com servicePrincipalName:
> root/hostname.example.com servicePrincipalName:
> cifs/hostname.example.com servicePrincipalName: host/hostname
> Kerberos: No preauth found, returning PREAUTH-REQUIRED --
> root/hostname.example.com at EXAMPLE.COM Kerberos: AS-REQ
> root/hostname.example.com at EXAMPLE.COM from ipv4:192.168.0.115:40299
> for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at EXAMPLE.COM))
> expr: (&(objectClass=user)(samAccountName=root/hostname.example.com))
> expr:
> (&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
> servicePrincipalName: host/hostname.example.com servicePrincipalName:
> nfs/hostname.example.com servicePrincipalName:
> HTTP/hostname.example.com servicePrincipalName:
> root/hostname.example.com servicePrincipalName:
> cifs/hostname.example.com servicePrincipalName: host/hostname
> Kerberos: Looking for PKINIT pa-data --
> root/hostname.example.com at EXAMPLE.COM Kerberos: Looking for ENC-TS
> pa-data -- root/hostname.example.com at EXAMPLE.COM Kerberos: ENC-TS
> Pre-authentication succeeded -- root/hostname.example.com at EXAMPLE.COM
> using arcfour-hmac-md5 Auth: [Kerberos KDC,ENC-TS Pre-authentication]
> user [(null)]\[root/hostname.example.com at EXAMPLE.COM] at [Thu, 12 Oct
> 2017 12:49:54.074861 CDT] with [arcfour-hmac-md5] status
> [NT_STATUS_OK] workstation [(null)] remote host
> [ipv4:192.168.0.115:40299] became [EXAMPLE]\[HOSTNAME$]
> [S-1-5-21-3036147387 -4093410917-1991690103-378605]. local host
> [NULL] authsam_account_ok: Checking SMB password for user
> root/hostname.example.com at EXAMPLE.COM logon_hours_ok: No hours
> restrictions for user root/hostname.example.com at EXAMPLE.COM Kerberos:
> TGS-REQ root/hostname.example.com at EXAMPLE.COM from
> ipv4:192.168.0.115:47146 for ldap/dc9.example.com at EXAMPLE.COM
> [canonicalize] expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at EXAMPLE.COM))
> expr: (&(objectClass=user)(samAccountName=root/hostname.example.com))
> Kerberos: Client no longer in database:
> root/hostname.example.com at EXAMPLE.COM
> 
> 
> 
> 
> 
> 
> As you can see, during the AS-REQ, the DC makes 3 queries for
> specific SPNs and returns positively after finding that last SPN.
> However, on the TGS-REQ, it only searches for 2 of those SPNs. It is
> a mystery to me why "expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at EXAMPLE.COM))"
> does not return -- it is not explicitly listed in the
> "servicePrinicipalName" attribute, but since
> "root/hostname.example.com" is and "@EXAMPLE.COM" is the realm, I
> would think it could figure it out. I'll keep looking into that;
> however, the lack of the last SPN search seems to me to be a bug.
> 
> Any thoughts?

Yes, you shouldn't have a user called 'root' in AD.
'root' is a Unix user and the AD user 'Administrator' should be mapped
to 'root'

Rowland