On Tue, Apr 17, 2018 at 2:27 AM, Sumit Bose <sbose(a)redhat.com> wrote:
On Mon, Apr 16, 2018 at 04:28:59PM -0400, James Ralston wrote:
> Has anyone figured out how to make sssd utilize a Microsoft
> read-only Domain Controller (RODC)?
>
> But no matter how we create the computer account object, or how we
> export the Kerberos keytab, sssd cannot use the resulting keytab
> file to authenticate to the RODC: when sssd sends the AS-REQ, the
> RODC always replies with KRB5KDC_ERR_PREAUTH_FAILED.
If 'kinit -k' works, SSSD should work as well.
Thanks; that's good to know.
Can you send the SSSD logs with debug_level=9, most important would
be the domain log and the ldap_child.log files.
For comparison it would be good to see the output of
KRB5_TRACE=/dev/stdout kinit -k ....
as well.
OK, I will look into that. (KRB5_TRACE especially seems like it will
be useful; I wasn't aware of that.)
I think part of why we're struggling here is because the behavior of
sssd doesn't seem to match its documentation.
Specifically…
For RWDCs, when I use Samba "net ads join" to create the computer
account in AD and write the /etc/krb5.keytab file, it always creates
multiple entries:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 host/myhost.example.org(a)EXAMPLE.ORG (des-cbc-crc)
2 host/myhost.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 host/myhost.example.org(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/myhost.example.org(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/myhost.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 host/MYHOST(a)EXAMPLE.ORG (des-cbc-crc)
2 host/MYHOST(a)EXAMPLE.ORG (des-cbc-md5)
2 host/MYHOST(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/MYHOST(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/MYHOST(a)EXAMPLE.ORG (arcfour-hmac)
2 MYHOST$(a)EXAMPLE.ORG (des-cbc-crc)
2 MYHOST$(a)EXAMPLE.ORG (des-cbc-md5)
2 MYHOST$(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 MYHOST$(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 MYHOST$(a)EXAMPLE.ORG (arcfour-hmac)
Using "adcli" does much the same thing, but additionally creates
RestrictedKrbHost SPNs:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 MYCLIENT$(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 MYCLIENT$(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 MYCLIENT$(a)EXAMPLE.ORG (des3-cbc-sha1)
2 MYCLIENT$(a)EXAMPLE.ORG (arcfour-hmac)
2 MYCLIENT$(a)EXAMPLE.ORG (des-cbc-md5)
2 MYCLIENT$(a)EXAMPLE.ORG (des-cbc-crc)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (des3-cbc-sha1)
2 host/myclient.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-crc)
2 host/MYCLIENT(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/MYCLIENT(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/MYCLIENT(a)EXAMPLE.ORG (des3-cbc-sha1)
2 host/MYCLIENT(a)EXAMPLE.ORG (arcfour-hmac)
2 host/MYCLIENT(a)EXAMPLE.ORG (des-cbc-md5)
2 host/MYCLIENT(a)EXAMPLE.ORG (des-cbc-crc)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (des3-cbc-sha1)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (arcfour-hmac)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (des-cbc-md5)
2 RestrictedKrbHost/MYCLIENT(a)EXAMPLE.ORG (des-cbc-crc)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG
(aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG
(aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (des3-cbc-sha1)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 RestrictedKrbHost/myclient.example.org(a)EXAMPLE.ORG (des-cbc-crc)
For adcli, this is the corresponding computer object in AD:
sAMAccountName: MYCLIENT$
sAMAccountType: 805306369
dNSHostName:
myclient.example.org
userPrincipalName: host/myclient.example.org(a)EXAMPLE.ORG
servicePrincipalName:
RestrictedKrbHost/myclient.example.org
servicePrincipalName: RestrictedKrbHost/MYCLIENT
servicePrincipalName:
host/myclient.example.org
servicePrincipalName: host/MYCLIENT
If use Samba to join the host to AD, the account is the same, minus
the RestrictedKrbHost SPNs.
According to the sssd-ldap(5) man page, ldap_sasl_authid defaults to:
host/hostname@REALM
However, this is ambiguous. Does this mean:
host/shorthostname@REALM
…or does it mean:
host/fqdn@REALM
I'm not sure.
But at least for AD, this doesn't seem to be what sssd is doing. We
don't set ldap_sasl_authid, but for hosts joined to a RWDC with a
keytab like the examples above, we can see in packet captures that
sssd defaults to using SHORTHOSTNAME$:
Kerberos AS-REQ
Pvno: 5
MSG Type: AS-REQ (10)
padata: PA-ENC-TIMESTAMP Unknown:149
Type: PA-ENC-TIMESTAMP (2)
…
Type: Unknown (149)
Value: <MISSING>
KDC_REQ_BODY
Padding: 0
KDCOptions: 00000010 (Renewable OK)
Client Name (Principal): MYCLIENT$
Name-type: Principal (1)
Name: MYCLIENT$
Realm:
EXAMPLE.ORG
Server Name (Service and Instance):
krbtgt/EXAMPLE.ORG
Name-type: Service and Instance (2)
Name: krbtgt
Name:
EXAMPLE.ORG
till: 2018-04-13 20:11:22 (UTC)
Nonce: 462670550
Encryption Types: …
Encryption type: aes256-cts-hmac-sha1-96 (18)
Encryption type: aes128-cts-hmac-sha1-96 (17)
Encryption type: rc4-hmac (23)
Encryption type: des-cbc-crc (1)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-md5-nt (20)
Encryption type: Unknown (19)
Encryption type: des3-cbc-sha1 (16)
Encryption type: Unknown (25)
Encryption type: Unknown (26)
Encryption type: des-cbc-md4 (2)
This behavior is why we've been trying to export a Kerberos keytab
file from AD that looks *exactly* like one that samba/adcli would
create. As we've discovered, that's not trivial.
But if in fact we don't need those additional entries—that just the
host/myclient.example.org(a)EXAMPLE.ORG entry in the keytab file is
sufficient for sssd—then that would help us immensely.
So: if the only thing in the /etc/krb5.keytab file is this:
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
2 host/myclient.example.org(a)EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 host/myclient.example.org(a)EXAMPLE.ORG (des3-cbc-sha1)
2 host/myclient.example.org(a)EXAMPLE.ORG (arcfour-hmac)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-md5)
2 host/myclient.example.org(a)EXAMPLE.ORG (des-cbc-crc)
…and the corresponding machine account in AD is:
sAMAccountName: MYCLIENT$
sAMAccountType: 805306369
dNSHostName:
myclient.example.org
userPrincipalName: host/myclient.example.org(a)EXAMPLE.ORG
servicePrincipalName:
host/myclient.example.org
Should that be sufficient for sssd to work correctly?
Thanks,
James