[Samba] Opensolaris-ish joins but does not seem to be valid
Mike Ray
mray at xes-inc.com
Wed Oct 11 22:56:50 UTC 2017
----- 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,
More information about the samba
mailing list