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

Norbert Hanke norbert.hanke at gmx.ch
Sun Feb 11 22:27:51 UTC 2018


Hi,

This thread has not been alive for a while...

I'm stuck at the same point: joining the Solaris 11.3 system works but 
using Samba-AD for Solaris-idmap does not work, failing during kerberos 
authentication.

Did you ever find a solution?

regards,

Norbert


On 12.10.2017 21:14, Mike Ray via samba wrote:
> ----- On Oct 12, 2017, at 1:52 PM, samba samba at lists.samba.org wrote:
>
>> 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'
>
> That makes sense. When I posted earlier, I overlooked that it was searching for
> that as a userPrinicpalName, not a servicePrincipalName. I do not have a "root"
> account in AD.
>
>
> What I don't understand is why that last SPN isn't getting checked in TGS-REQ
> but is in the AS-REQ.
>




More information about the samba mailing list