Data in ServicePrincipalName AD attribute gets removed

[ianmb]

We are predominantly a Windows shop and bind our Macs to our existing AD infrastructure. Our MacBooks rely on the ServicePrincipal attribute being populated in AD with the following data in order to connect to our corporate 802.1X wifi network:

afpserver/machinename.company.com
cifs/machinename.company.com
host/machinename.company.com
vnc/machinename.company.com

And our home-grown network registration system populates the attribute with the relevant data, appropriate for the machine. However, we are currently finding that the data within that attribute disappears occasionally for some machines, meaning that the relevant MacBook can’t connect to our wifi network. I have to get someone in our operations team to add in the data manually if it disappears.

Our AD guys have trawled any pertinent logs and cannot find any good reason why that data should disappear. Has anyone come across this before, and could it conceivably be the Mac client causing the attribute data to be lost? I can see a ‘last modified’ date on the computer record but this isn’t consistent with the time the client was bound to AD or connected to the wifi network. There just seems to be no pattern.

If anyone has any words of wisdom I will be more than happy to receive them! We have Microsoft Premier support but no Apple Enterprise support, and MS would like us to exhaust everything at the Apple end initially.

[alexjdale]

This is very interesting. We actually had this as a bug in one of the older OS versions (way back, around 10.7 I think). The SPN record in AD was disappearing, just like this.

We'd track it with an extension attribute that ran

dscl . read Computers/localhost | grep KerberosServices

which should return "KerberosServices: host afpserver cifs vnc" (I think there are more entries nowadays) but sometimes it just randomly blanked out. It would then push that change to its AD record when it connected to the network. This meant if we fixed the AD record directly, it would blank out again the next time the system connected. The only real fix was another dscl command to recreate that above localhost entry, so the next time the client connected to the network it would repair the AD record.

That said, it was fixed in the OS years ago and hasn't been an issue since, but we don't have a home-grown system to populate the data and relied on the clients. I'd check to see what your clients are reporting with the above dscl command.

[ianmb]

Many thanks for this.

Shortly after I posted, I came across this thread and the workaround that @Aaron mentions of:

dscl . -create Computers/localhost kerberosServices host

.....seems to be working well for us so far, with the Macs that have data in the ServicePrincipalName attribute missing.

[cbrewer]

Tossing this in here for future reference. Script to reset SPN's on a Mac's AD computer record.

#!/bin/bash


# Check KerberosServices entry in dscl - needed for missing ServicePrincipalNames in AD computer record

# Script only tested thru 10.14
osvers=$(sw_vers -productVersion | awk -F. '{print $2}')
if [[ ${osvers} -ge 15 ]]; then
  echo "macOS $(sw_vers -productVersion) not tested with this script."
  exit 0
fi

adComputerName=$(dsconfigad -show | grep "Computer Account" | awk '{print $4}')

if [[ ! "$adComputerName" ]]; then
    echo "Not Bound to AD. Exiting."
    exit 0
else
    echo "Bound to AD as $adComputerName"
fi

if [[ $(dscl . read /Computers/localhost KerberosServices | grep "host") ]]; then
  echo "KerberosServices already set"
  exit 0
else
  echo "Adding KerberosServices entries"
  dscl . create /Computers/localhost KerberosServices host afpserver cifs vnc
  sleep 5  
  killall opendirectoryd
fi

[mark_mahabir]

@cbrewer Many thanks for this.

We have (occasionally) been seeing the same issue and this script saves quite a few keystrokes when it does occur!

[isThisThing0n]

Script is useful. Anyone know what is actually causing the missing attribute?