[SSSD-users] Re: does sssd support using a Microsoft read-only Domain Controller (RODC)?

[James Ralston]

On Tue, Apr 17, 2018 at 2:27 AM, Sumit Bose <sbose(a)redhat.com&gt; 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