On Tue, Apr 17, 2018 at 2:27 AM, Sumit Bose <sb...@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....@example.org (des-cbc-crc)
2 host/myhost.example....@example.org (des-cbc-md5)
2 host/myhost.example....@example.org (aes128-cts-hmac-sha1-96)
2 host/myhost.example....@example.org (aes256-cts-hmac-sha1-96)
2 host/myhost.example....@example.org (arcfour-hmac)
2 host/myh...@example.org (des-cbc-crc)
2 host/myh...@example.org (des-cbc-md5)
2 host/myh...@example.org (aes128-cts-hmac-sha1-96)
2 host/myh...@example.org (aes256-cts-hmac-sha1-96)
2 host/myh...@example.org (arcfour-hmac)
2 MYHOST$@EXAMPLE.ORG (des-cbc-crc)
2 MYHOST$@EXAMPLE.ORG (des-cbc-md5)
2 MYHOST$@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 MYHOST$@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 MYHOST$@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$@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
2 MYCLIENT$@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
2 MYCLIENT$@EXAMPLE.ORG (des3-cbc-sha1)
2 MYCLIENT$@EXAMPLE.ORG (arcfour-hmac)
2 MYCLIENT$@EXAMPLE.ORG (des-cbc-md5)
2 MYCLIENT$@EXAMPLE.ORG (des-cbc-crc)
2 host/myclient.example....@example.org (aes256-cts-hmac-sha1-96)
2 host/myclient.example....@example.org (aes128-cts-hmac-sha1-96)
2 host/myclient.example....@example.org (des3-cbc-sha1)
2 host/myclient.example....@example.org (arcfour-hmac)
2 host/myclient.example....@example.org (des-cbc-md5)
2 host/myclient.example....@example.org (des-cbc-crc)
2 host/mycli...@example.org (aes256-cts-hmac-sha1-96)
2 host/mycli...@example.org (aes128-cts-hmac-sha1-96)
2 host/mycli...@example.org (des3-cbc-sha1)
2 host/mycli...@example.org (arcfour-hmac)
2 host/mycli...@example.org (des-cbc-md5)
2 host/mycli...@example.org (des-cbc-crc)
2 RestrictedKrbHost/mycli...@example.org (aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/mycli...@example.org (aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/mycli...@example.org (des3-cbc-sha1)
2 RestrictedKrbHost/mycli...@example.org (arcfour-hmac)
2 RestrictedKrbHost/mycli...@example.org (des-cbc-md5)
2 RestrictedKrbHost/mycli...@example.org (des-cbc-crc)
2 RestrictedKrbHost/myclient.example....@example.org
(aes256-cts-hmac-sha1-96)
2 RestrictedKrbHost/myclient.example....@example.org
(aes128-cts-hmac-sha1-96)
2 RestrictedKrbHost/myclient.example....@example.org (des3-cbc-sha1)
2 RestrictedKrbHost/myclient.example....@example.org (arcfour-hmac)
2 RestrictedKrbHost/myclient.example....@example.org (des-cbc-md5)
2 RestrictedKrbHost/myclient.example....@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....@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....@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....@example.org (aes256-cts-hmac-sha1-96)
2 host/myclient.example....@example.org (aes128-cts-hmac-sha1-96)
2 host/myclient.example....@example.org (des3-cbc-sha1)
2 host/myclient.example....@example.org (arcfour-hmac)
2 host/myclient.example....@example.org (des-cbc-md5)
2 host/myclient.example....@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....@example.org
servicePrincipalName: host/myclient.example.org
Should that be sufficient for sssd to work correctly?
Thanks,
James
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
