Active Directory Extension attributes return empty value or error after second inventory update

[Abdelhafid]

Hey everyone,

I'm currently seeing the following issue;

We have 2 extension attributes that we use to return the Active Directory OU and group memberships of the computer object. After a small pilot with no issues we've deployed hundreds of machines and i'm seeing that the active directory attributes are empty or return the following error

source (/Active Directory/ourdomainname/All Domains) is not valid.

I can ping the machines and when I remote into the machines I can logon with an active directory account. JAMF also reports that the machine is bound to an Active Directory. When triggering a manual recon the value seems to be filled correctly but since we use the attributes to scope config profiles and software we don't want to this information to go blank since configuration profiles are removed including a wifi profile which makes it difficult to fix this issue.

The machines are running osx 10.8.5. I can't seem to reproduce the issue on our test machines. To circumvent the problem I have modified one of the extension attributes to return info from the jss database using the API when for whatever reason a blank Active Directory OU is returned. However the recon does not seem to be querying the API. So i'm suspecting the machines are not using the latest extension attribute scripts for some reason.

I'm wondering if the JAMF Community has any idea why the extension attributes are not returning an active directory value. I'm suspecting it has something to do with sleep since the machines are not being used yet they seem to have woken up and running policies. Are updated extension attributes used immediatly when they are modified or does the client need to cache the extension attribute scripts first? Below are the extension attributes that we are using.

I've already created a support case but I was wondering if anyone has run into this issue or has any pointers for me. I'd rather not disable the inventory update to prevent any more machines from returned empty AD attributes.

================= 
Active Direcory OU EA 
#!/bin/sh 

ad_computer_name=`dsconfigad -show | grep "Computer Account" | awk '{print $4}'` ad_computer_ou=`dscl /Search read /Computers/$ad_computer_name |  grep -A 1 dsAttrTypeNative:distinguishedName |  cut -d, -f2- | sed -n 's/OU=//gp' |  sed -n 's/(.*),DC=/1./gp' |  sed -n 's/DC=//gp' |  awk -F, '{ N = NF while ( N > 1 ) { printf "%s/",$N N-- } printf "%s",$1 }'` 

#I have noticed that sometimes this extension attribute return nothing at all. It most likely errors out for some reason but this value needs to be set correctly to prevent Configuration profiles from 
#being removed since the smart groups they are scoped to are based on this value. 
#Since ive seen this happening only 3 times and am unable to troubleshoot it I have added the code below to set the value to its last value. This value normally does not change at all so this is an acceptable #compromise to prevent computers from losing their among others wifi config profiles and generating support tickets. 

if [[ -z $ad_computer_ou ]] 
 then 
    apiURL='https://server:8443/JSSResource/computers/udid/' 
    apiUser='user' 
    apiPass='password' 
    extAttName=""Active Directory OU"" udid=$(/usr/sbin/system_profiler SPHardwareDataType | /usr/bin/awk '/Hardware UUID:/ { print $3 }')   ad_computer_ou=$(curl -s -u $apiUser:$apiPass $apiURL$udid/subset/extension_attributes | xpath "//extension_attribute[name=$extAttName]" 2>&1 | awk -F'<value>|</value>' '{print $2}') 
 fi 
echo "<result>"$ad_computer_ou"</result>"
...


=============================================== 
 #!/bin/sh 
OFS="
" 
AdCompName=$( dsconfigad -show | awk '/Computer Account/{print $NF}' ) Groups=$(dscl /Active Directory/domainname/All Domains read /computers/$AdCompName dsAttrTypeNative:memberOf | cut -d " " -f2- | awk -F "CN=" '{for (i = 0; ++i <=NF;) print $i}' | awk -F "," '{print $1}' | sed '/^$/d') 
echo "<result>$Groups</result>"

[Abdelhafid]

After getting another machine this morning with a blank AD extension attribute I checked and I noticed that the machine seemed to be waking up every 2 hours and sometimes running policies in this time.

I'm suspecting that in those mode the dscl command is not reliable or can't query it's active directory status. Research on the internet specified that this Wake on Demand feature can be disabled by disabling WOL.

I disabled WOL and will monitor the machines. It's an odd issue though.

[davidacland]

The source (/Active Directory/ourdomainname/All Domains) is not valid message is normally displayed when a Mac can't read AD. This would happen when a Mac first wakes from sleep as it can take a little while for the connection to the domain controller to re-establish.

I quick solution might be to extent the script to check the output. If you get source (/Active Directory/ourdomainname/All Domains) is not valid, get it to wait for 60 seconds and try again.

Not sure which way you're checking for AD connectivity. If its one of the standard EAs or the base JSS inventory method this will only say that the Mac is configured to connect to AD, not that it actually is connected. Fr example, you can run dsconfigad -show on a Mac with no network connection and it will give info about the domain it is connected to. But if you tried any dscl commands, they would fail.

There are a few other threads on here about alternative (better) EAs people are using to really check if the Mac has a connection to AD.

[Abdelhafid]

Hi david,

Thank for the reply.

I'm checking which AD organizational unit the computer belongs too and as far as I can tell using the dscl command is the only way. I actually got the connection EA which checks the ou from JamfNation :).

I suppose I can build in a sleep into the Extension Attribute and check if that helps.

[mm2270]

We've had similar issues with our AD verification EA script. How we got around it is, our script first looks to see if the Mac can ping our primary domain controller, then if successful, moves on to checking AD status. Otherwise it exits and reports "Remote" as the result in the EA. When we see Remote we know the Mac was checking in from outside the company network or was not on VPN and so we can't really verify the settings.
While we could have had it loop by waiting a minute, since we have a clustered JSS with one part in the DMZ, Macs can check in from any internet connection, so we would have needed to put in a max number of attempts before it simply stopped, or the loop would continue indefinitely. We preferred to simply report that it was not able to see the DC and/or AD and exit.

[mm2270]

On second thought, what may be better in your case is to write the OU value to a local file or plist once it checks once successfully, and then read that back if the file/value is present later. How often do your Macs change the OU they are in? If they don't move around ever, that may be a better approach than doing a dscl lookup every time they recon.

[Abdelhafid]

We use the OU path to target Config Profiles so we rather not have any other value in the EA that an valid OU.

Writing out the OU path to a config profile is interesting. I'll be sure to try the 60 second pause and writing a successful AD query to a plist/Text file that is used when dscl does not return a value.

[dwandro92]

For what it's worth, I use a different method for getting Active Directory OU, and I have not seen any issues with it. Refer to my response to another thread for more details.