0

I'm trying to set up a Windows 2019 system as an SMB server to work with third-party software on an external, non-Windows system that uses Kerberos to authenticate to the SMB server. This SMB server is joined to an existing Active Directory domain on a separate Domain Controller server. Although the software is successful in getting both user and SPN credentials from the Windows AD Kerberos server, the SMB server rejects those credentials with the error KRB5KRB_AP_ERR_MODIFIED.

The SMB user is defined in AD, and there is a computer account for the SMB server in AD as well. Although the SPN list in the DC account does not have this SMB server, the SPN list in the computer account for the SMB server does. I tried to manually add an SPN entry for the SMB server on the DC, but it was rejected because it's a duplicate, so I presume that the DC takes the SMB server computer account into consideration when looking for duplicates.

I've seen this kind of problem before, and it's usually an issue with DNS entries where the SMB server thinks its host name is one thing but the Kerberos server and/or third-party software think it's something else. In this case, though, the situation is slightly different--the rejection in the Session Setup Response shows the SMB server name as its short host name followed by a dollar sign. This is despite the fact that the full computer name of the SMB server on the SMB server is its DNS FQDN (this is according to the System program in the Control Panel). I also verified that the DNS server (which is also the AD DC) correctly resolves the SMB server's host name and IP address.

Here is the sequence of events:

  1. The client software on a non-Windows system connects to the SMB server over TCP and, using SMBv2, successfully performs protocol negotiation.
  2. The client software requests credentials for the SMB user from the Kerberos server (AD DC) via an AS-REQ and receives a positive AS-REP with the credentials. (I verified that the correct Kerberos realm name is used, and that the sname values in the request and response match up.)
  3. The client software then requests credentials for the SPN of the SMB server in a TGS-REQ sent to the Kerberos server. The SPN value it uses is "cifs/DNS_FQDN", where "DNS_FQDN" is the fully qualified DNS host name of the SMB server. It receives those credentials in a positive TGS-REP. (I verified that the correct Kerberos realm name is used, and that the sname values in the request and response match up.)
  4. The client software puts those credentials in a GSS-API security blob inside an SMB Session Setup Request and sends the request to the SMB server.
  5. The SMB server rejects the credentials with the error KRB5KRB_AP_ERR_MODIFIED. The realm name in the security blob in the Session Setup Response packet is correct, but the sname string of the SMB server in the response is the short host name of the server followed by a dollar sign.

Clearly, I haven't configured something correctly. The third-party software works with SMB shares on the AD DC; it just doesn't work with shares on the separate SMB server, and then only because the SMB server rejects the credentials given to the third-party software by the Kerberos server.

What am I doing wrong? Should I remove the SMB computer account on the AD DC and then manually add an SPN entry for the SMB server on it? Is there something I need to add to or modify in the SMB computer account? Do I need to change something on the SMB server so that it recognizes "cifs/DNS_FQDN" as being valid?

Steve Talmage
  • 1
  • `The client software then requests credentials for the SPN of the SMB server`. I'm not sure why you are calling it "SPN Credentials". An SPN is just a name - for the service that you are connecting to. E.g. fileserver.acme.com. The only credentials in this case are the username and password, and the only principal for those credentials is the user account. AD doesn't provide credentials for computer accounts, nor would it need to. – Greg Askew Aug 25 '22 at 19:04
  • I'm still not sure what you've done so far, exactly, but have you tried _not_ doing anything at all? This should have _immediately_ worked as soon as you joined the server to AD, without any changes to the SPN configuration in AD. (The 'cifs' service is aliased to 'host' by AD KDCs, therefore SPNs for it do not need to be listed explicitly.) Are you cloning the SMB server from a template? Did you join it to AD yourself or was it already joined when you got to it? After you've restored the SPN lists to normal, can you check if running `Reset-ComputerMachinePassword` on the SMB server helps? – user1686 Aug 26 '22 at 04:43
  • But also, could you manually search AD to see if some _other_ account (possibly a user account) happens to have the `cifs/*` SPN assigned? – user1686 Aug 26 '22 at 04:45
  • Greg: I referred to them as SPN credentials because the third-party software sends a TGS-REQ for the SPN "cifs/FQDN" to the Kerberos (AD) server and gets back what I presume to be credentials in a TGS-REP. If they're not credentials, then what are they? – Steve Talmage Aug 26 '22 at 20:08
  • user1686: Unfortunately, the SMB server came to me already joined to the AD domain, and with various (and undocumented) changes made to it. I inherited it from a person who was laid off, so I can't ask them what they did. (Yes, I know about the alias from cifs to host.) Also, I'm not sure what you mean by "restore the SPN lists to normal". I checked all the user accounts and all but one have no servicePrincipalName values at all. The only one that does is for the change password service of kadmin. – Steve Talmage Aug 26 '22 at 20:11
  • @SteveTalmage: ask the vendor of the mystery application. – Greg Askew Aug 27 '22 at 13:10
  • @GregAskew They don't know either, which is why I posted my question. – Steve Talmage Aug 28 '22 at 19:29
  • @user1686 Sorry. I forgot to put an @ on your name an earlier post of mine. I'm not sure if you saw it. – Steve Talmage Aug 29 '22 at 18:52

0 Answers0