thr3ads.net - samba - [Samba] Opensolaris-ish joins but does not seem to be valid [Oct 2017]

If this information is useful, please help other people find it:
Share via:

Mike Ray

2017-Oct-11 22:56 UTC

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

----- 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.

After joining this machine to the domain, it goes through a process that it
calls "AD/Kerberos Setup". Comparing to the working counterpart on the
old
domain, this process appears to set the domain name, a DN search base (sets to
Schema) and then lists the GC servers. 

What follows is a tcpdump of port 88 during that "AD/Kerberos Setup":




No.     Time        Source                Destination           Protocol Length
Info
      1 0.000000    192.168.0.115           192.168.6.6             KRB5     241
AS-REQ

Frame 1: 241 bytes on wire (1928 bits), 241 bytes captured (1928 bits)
User Datagram Protocol, Src Port: 55231 (55231), Dst Port: kerberos (88)
Kerberos AS-REQ
    Pvno: 5
    MSG Type: AS-REQ (10)
    KDC_REQ_BODY
        Padding: 0
        KDCOptions: 00000010 (Renewable OK)
        Client Name (Service and Host): root/host.example.com
            Name-type: Service and Host (3)
            Name: root
            Name: host.example.com
        Realm: EXAMPLE.COM
        Server Name (Principal): krbtgt/EXAMPLE.COM
            Name-type: Principal (1)
            Name: krbtgt
            Name: EXAMPLE.COM
        from: 2017-10-11 22:30:52 (UTC)
        till: 2017-10-12 08:30:52 (UTC)
        Nonce: 1507761052
        Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
des3-cbc-sha1 rc4-hmac rc4-hmac-exp des-cbc-md5 des-cbc-crc
        HostAddresses: 192.168.0.115

No.     Time        Source                Destination           Protocol Length
Info
      2 0.002177    192.168.6.6             192.168.0.115           KRB5     303
KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

Frame 2: 303 bytes on wire (2424 bits), 303 bytes captured (2424 bits)
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 55231 (55231)
Kerberos KRB-ERROR
    Pvno: 5
    MSG Type: KRB-ERROR (30)
    stime: 2017-10-11 22:30:57 (UTC)
    susec: 26559
    error_code: KRB5KDC_ERR_PREAUTH_REQUIRED (25)
    Client Realm: EXAMPLE.COM
    Client Name (Service and Host): root/host.example.com
        Name-type: Service and Host (3)
        Name: root
        Name: host.example.com
    Realm: EXAMPLE.COM
    Server Name (Principal): krbtgt/EXAMPLE.COM
        Name-type: Principal (1)
        Name: krbtgt
        Name: EXAMPLE.COM
    e-text: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ
    e-data
        padata: PA-ENC-TIMESTAMP PA-DASS PA-PK-AS-REP PA-ENCTYPE-INFO
PA-ENCTYPE-INFO2
            Type: PA-ENC-TIMESTAMP (2)
                Value: <MISSING>
            Type: PA-DASS (16)
                Value: <MISSING>
            Type: PA-PK-AS-REP (15)
                Value: <MISSING>
            Type: PA-ENCTYPE-INFO (11)
                Value: 30073005a003020117 rc4-hmac
                    Encryption type: rc4-hmac (23)
            Type: PA-ENCTYPE-INFO2 (19)
                Value: 30073005a003020117 rc4-hmac
                    Encryption type: rc4-hmac (23)

No.     Time        Source                Destination           Protocol Length
Info
      3 0.003199    192.168.0.115           192.168.6.6             KRB5     321
AS-REQ

Frame 3: 321 bytes on wire (2568 bits), 321 bytes captured (2568 bits)
User Datagram Protocol, Src Port: 60405 (60405), Dst Port: kerberos (88)
Kerberos AS-REQ
    Pvno: 5
    MSG Type: AS-REQ (10)
    padata: PA-ENC-TIMESTAMP
        Type: PA-ENC-TIMESTAMP (2)
            Value: 303da003020117a23604341f02bfb4cefe9338f229dd3b57... rc4-hmac
                Encryption type: rc4-hmac (23)
                enc PA_ENC_TIMESTAMP:
1f02bfb4cefe9338f229dd3b578ab9b6e6b65709a5c50761...
    KDC_REQ_BODY
        Padding: 0
        KDCOptions: 00000010 (Renewable OK)
        Client Name (Service and Host): root/host.example.com
            Name-type: Service and Host (3)
            Name: root
            Name: host.example.com
        Realm: EXAMPLE.COM
        Server Name (Principal): krbtgt/EXAMPLE.COM
            Name-type: Principal (1)
            Name: krbtgt
            Name: EXAMPLE.COM
        from: 2017-10-11 22:30:52 (UTC)
        till: 2017-10-12 08:30:52 (UTC)
        Nonce: 1507761052
        Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
des3-cbc-sha1 rc4-hmac rc4-hmac-exp des-cbc-md5 des-cbc-crc
        HostAddresses: 192.168.0.115

No.     Time        Source                Destination           Protocol Length
Info
      4 0.014971    192.168.6.6             192.168.0.115           KRB5    
1381   AS-REP

Frame 4: 1381 bytes on wire (11048 bits), 1381 bytes captured (11048 bits)
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 60405 (60405)
Kerberos AS-REP
    Pvno: 5
    MSG Type: AS-REP (11)
    Client Realm: EXAMPLE.COM
    Client Name (Service and Host): root/host.example.com
        Name-type: Service and Host (3)
        Name: root
        Name: host.example.com
    Ticket
        Tkt-vno: 5
        Realm: EXAMPLE.COM
        Server Name (Principal): krbtgt/EXAMPLE.COM
            Name-type: Principal (1)
            Name: krbtgt
            Name: EXAMPLE.COM
        enc-part rc4-hmac
    enc-part rc4-hmac

No.     Time        Source                Destination           Protocol Length
Info
      5 0.015978    192.168.0.115           192.168.6.6             KRB5    
1438   TGS-REQ

Frame 5: 1438 bytes on wire (11504 bits), 1438 bytes captured (11504 bits)
User Datagram Protocol, Src Port: 64049 (64049), Dst Port: kerberos (88)
Kerberos TGS-REQ
    Pvno: 5
    MSG Type: TGS-REQ (12)
    padata: PA-TGS-REQ
        Type: PA-TGS-REQ (1)
            Value: 6e8204c4308204c0a003020105a10302010ea20703050000... AP-REQ
                Pvno: 5
                MSG Type: AP-REQ (14)
                Padding: 0
                APOptions: 00000000
                Ticket
                    Tkt-vno: 5
                    Realm: EXAMPLE.COM
                    Server Name (Principal): krbtgt/EXAMPLE.COM
                        Name-type: Principal (1)
                        Name: krbtgt
                        Name: EXAMPLE.COM
                    enc-part rc4-hmac
                Authenticator rc4-hmac
    KDC_REQ_BODY
        Padding: 0
        KDCOptions: 00010000 (Canonicalize)
        Realm: EXAMPLE.COM
        Server Name (Service and Host): ldap/dc9.example.com
            Name-type: Service and Host (3)
            Name: ldap
            Name: dc9.example.com
        till: 2017-10-12 08:30:52 (UTC)
        Nonce: 1507761057
        Encryption Types: aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
des3-cbc-sha1 rc4-hmac rc4-hmac-exp des-cbc-md5 des-cbc-crc
        HostAddresses: 192.168.0.115

No.     Time        Source                Destination           Protocol Length
Info
      6 0.018414    192.168.6.6             192.168.0.115           KRB5     148
KRB Error: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN

Frame 6: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits)
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 64049 (64049)
Kerberos KRB-ERROR
    Pvno: 5
    MSG Type: KRB-ERROR (30)
    ctime: 2017-10-11 22:30:57 (UTC)
    cusec: 234
    stime: 2017-10-11 22:30:57 (UTC)
    susec: 42801
    error_code: KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN (6)
    Realm: <unspecified realm>
    Server Name (Unknown):
        Name-type: Unknown (0)





As you can see, the machine makes an AS-REQ to the DC, which returns an AS-REP
indicating everything is OK. Then to get the ticket-granting ticket (TGT), the
machine makes a TGS-REQ to the same DC. However, instead of receiving the
TGS-REP, the machine receives an error from the DC stating that the principal
could not be found. How is that happening? Isn't the principal just
"root/host.example.com"? I can verify that the
"servicePrincipalName" attribute
for that computer object has "root/host.example.com" listed. Isn't
the TGS-REQ
authenticated by the ticket response (AS-REP)? What could make the ticket
included in the AS-REP instantly invalid?

Any insights would be appreciated.

Thanks,

Mike Ray

2017-Oct-12 18:28 UTC

head link

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

----- 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?

Rowland Penny

2017-Oct-12 18:52 UTC

head link

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

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

Apparently Analagous Threads

Search for more reasonably related threads

samba - Oct 2017 - Opensolaris-ish joins but does not seem to be valid

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

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

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

Apparently Analagous Threads