Please note that Windows Server does case insensitive compares of the Kerberos service principal 'service/cname', where the service principal is of the form 'service/cname@AD.REALM.ORG'

Created attachment 18520 [details]
Patch for fixing sync_spns and spn_prefixes

Fix I worked out to make sync_spns/spn_prefixes produce default text in service principal names in lower case, in line with RFC 4120 section 6.2.1

We had looked at it with Pavel on Friday, here are some notes.

- service names are case sensitive and actually set in stone for most protocols outside of Active Directory/Kerberos specs. 'host/' cannot be 'HOST/', but 'HTTP/' cannot be 'http/'. This means all-lowcasing or all-upcasing is not possible.

- MSFT specs don't do justice for SPNs definitions. There are also confusing statements where SPNs defined in MSFT documentation by explaining certain service names in all-caps (e.g. HOST) throughout a document and never saying this is an example.

- multi-part principals will have to have *some* parts case-preserved. E.g. ldap/<hostname>/<REALM>@<REALM> or ldap/<hostname>/<NETBIOS>@<REALM>.

I suspect HOST/ SPN comes from Samba's ~15-20 years old mistake of reading specs. RFC 4120 6.2.1 does only say that for DNS-based hostnames they must be low-cased but it says nothing about the service identifier (e.g. host/ or HTTP/). This is intentional because Kerberos principals are case-sensitive by RFC definitions, as well as Kerberos realms.

MSFT docs:

- https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-kile/04033bd5-913c-4c78-a398-b549b09e65d9 (MS-KILE 3.1.5.11)

- https://learn.microsoft.com/en-us/windows/win32/ad/service-principal-names, make sure to read the whole section

- https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/599d1fe8-0549-4653-bdce-cb51965c19ae (MS-DRSR 2.2.2) is an example of a protocol-specific definition with an upper case service class.

- https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/41efc56e-0007-4e88-bafe-d7af61efd91f (MS-DRSR 2.2.3.2) is an example of guid-based SPNs that probably should not be low-cased at all.

- https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/3c154285-454c-4353-9a99-fb586e806944 (MS-ADTS 3.1.1.5.1.3) is an example of a confusing naming of the service classes that use CIFS/ and HOST/ upper case while they really should not be used this way.

Problem is the sync_spns and spn_prefixes produce default information that breaks Unix daemons, and installs raw SPNs with upper case components that are contrary to their default settings.

Sssd breaks, as well as sshd, for kerberos authentication after upgrade to Samba 4.21.  Changes introduced should NOT break things unexpectedly.  I am going to log this as a Debian bug, along with the patch I produced above.

The transformation I have come up with in the patch modifies the Posix system keytab by lower casing the default components of the SPN string, and does NOT touch the contents of the AD SPN database.

The most important thing is to produce winbind keytab that does not break AD joined Linux clients.

I am working on addition of new keytab SPN specifiers which will address also this issue.
Draft is here: https://gitlab.com/samba-team/samba/-/merge_requests/3925

The solution is not to lowercase the "servicePrincipalNames" from AD (which is wrong in general)  but to construct a principal 'host/machine.ad.realm.org@AD.REALM.ORG' and also MACHINE$@AD.REALM.ORG using new syntax.

These two changes will provide a solution:

- new specifier 'host'
- new syntax will allow to add a list of spn specifiers

It will allow to use this:

sync machine password to keytab = /etc/krb5.keytab:host:account_name:sync_spns:sync_kvno:machine_password

This bug was referenced in samba master:

15e191736d3eaba83b2fb4b901e1df2214526b64
7a662e097be5e0d3f7779fa544486968b8f57063

Created attachment 18560 [details]
4.21 patch

Created attachment 18561 [details]
4.22 patch

Jule, please apply the patches the the corresponding branches. Thanks!

(In reply to Andreas Schneider from comment #9)

Jule, please wait for additional patches as discussed...

This bug was referenced in samba master:

ccc3b2b2fba7b5d223c79bffc0f655490aed19cf
7cae7aad1ca6dcd5e0a3a102f36af74fa49a2c2b

Created attachment 18565 [details]
4.22 patch

Created attachment 18566 [details]
4.21 patch

Jule, this is ready now

(In reply to Pavel Filipenský from comment #13)

No patch for 4.20?

The new keytab code was first released with 4.21, no need to patch 4.20 (In reply to Stefan Metzmacher from comment #15)

(In reply to Matthew Grant from comment #0)

The upstream fix and the attached patch adds the possibility to put multiple specifiers for the same keytab. To have both 'host' and COMPUTER$ principals add the 'account_name' and 'spn_prefixes=host'. So it can be e.g.:

sync machine password to keytab = /etc/krb5.keytab:account_name:spn_prefixes=host:sync_spns:sync_kvno:machine_password

Pushed to autobuild-v4-{22,21}-test.

This bug was referenced in samba v4-21-test:

58a7666b6788b68b82bf9f178e8e42d9e2c3fac3
8d5384e965f86fdc40f01654b6f401b2faf4e3b7
63b115a0092dbf38f8b519b9a469b758b0f3dbf0
cead38fb09647ca20bf489c808f39df993316f12

This bug was referenced in samba v4-21-stable (Release samba-4.21.4):

58a7666b6788b68b82bf9f178e8e42d9e2c3fac3
8d5384e965f86fdc40f01654b6f401b2faf4e3b7
63b115a0092dbf38f8b519b9a469b758b0f3dbf0
cead38fb09647ca20bf489c808f39df993316f12

This bug was referenced in samba v4-22-test:

430591895969d092256de295dd095c530272cf88
5b5862dc690ad0d546f8b11d21e231f556475e05
cb50befaa2107882fb465f7770038246e31d82d4
b9c08aec94a6bf41fd7fe7f810349b3c243542ba

Closing out bug report.

Thanks!

This bug was referenced in samba v4-22-stable (Release samba-4.22.0rc3):

430591895969d092256de295dd095c530272cf88
5b5862dc690ad0d546f8b11d21e231f556475e05
cb50befaa2107882fb465f7770038246e31d82d4
b9c08aec94a6bf41fd7fe7f810349b3c243542ba