Bind to AD Process

[edullum]

I'm out of time and ideas. If you have any input regarding HOW I can achieve the end goal, please chime in! Beers for everyone!

Goal: During enrollment of computers we want the end user to be able to log into the machine with their AD credentials after they complete the setup assistant.

Issue: The computer fails to bind to AD; therefore leaving the end user unable to log into the computer. We skip the "create local account" in Prestage.

Failure: The failure occurs with the Configuration Profile to bind to AD. I receive an error message: The server ‘DIRECTORYSERVER.ABC.org’ either couldn’t be found, or was not responding.

Workaround: Deleting the failed command to bind to AD, excluding the machine from the scope of the profile, sending a blank push, then rescoping the machine to the bind to AD profile successfully delivers the config profile. This is NOT an ideal workflow and this process can't be babysat.

Components to achieve this goal:
Environment: Jamf Pro v10.5
Enrollment Method: DEP/Prestage
Config Profiles: Bind to AD Scope: All Managed Computers
Policies: Computer Name Change Script: Trigger: Once per computer after Enrollment is Complete

#!/usr/bin/env bash

# Get the Serial Number of the Machine
sn=$(system_profiler SPHardwareDataType | awk '/Serial/ {print $4}')

# Set the ComputerName, HostName and LocalHostName
scutil --set ComputerName $sn
scutil --set HostName $sn
scutil --set LocalHostName $sn

I've tried using the IP address and the host name of the directory server and they both initially fail.

Theory: Is it possible that the machine is trying to bind to AD before the name change? There was a thought to create a smartgroup based on a name change and then scope the bind to AD profile to that smartgroup. However, I don't fully trust smartgroups.

[sam_g]

Any reason you're not binding during the prestage enrollment? Or is that the config profile that's being pushed? If so - any attempts at using a policy to do the binding instead of a config profile?

[OmarB]

Hi,

Do you know what the process is for binding during the prestage enrollement?

[Geelcey]

Are machines cabled in???? have you pinged the FQDN from the network they are on? Have you tried bidning manually from one of the machines and does it work? Do they have a wifi profile pushed out to them aswell?

Sorry to ask but it will help me pin point where the issue lays :) Also i presume you have double checked all of your directory settings etc

Oh ps. check the time of the macs and the time on the server.

G

[edullum]

@float0n We are pushing the binding with a config profile in the event that we need to change the directory settings. It would be easier to change it in a config profile and reapply the profile to all machines. Setting up the binding in prestage is more of permanent thing. If we need to change the binding on machines that received the directory payload from prestage, we would have to remove the payload somehow and then push out a config profile. If there is a way to bind to AD with a policy, I'd like to test that. Do you have instructions?

@Geelcey The iMacs and Mac Minis were hardwired with ethernet. The users enrolling macbooks are prompted to log into the secured wireless network we have. The DC that is binding them to AD is pingable. We have four DCs, however there is a limitation of Jamf Pro only allowing one DC to be configured as the Directory Server in the Directory payload. The machines bind manually just fine. Machines do not have a wifi profile pushed out to them. I tested this with an unsecured guest wireless profile and the binding failed, but that could also be related to the limitations of the wireless profile. During enrollment, we instruct users to enable location services and then select the current time zone. I have a policy to run to change the time zone on the macs if the user skips that in the setup assistant. But with the testing I have done, I have selected the correct time zone.

Thank you for the questions!

[sam_g]

@edullum Is changing the settings for AD really something you think you'll be doing often? I'd try to not over complicate things and just use the binding settings from the prestage enrollment. If for some reason you need to change settings in the future, you can push out a config profile/script/policy then.

As far as the policy goes - just create a new policy and you'll see the option in there for directory binding. You can then have it trigger on enrollment complete or check in or whatever you prefer.

[edullum]

I tested this by creating a policy and it was successful.
1) I added the name change script to run BEFORE 2) I added the Directory Binding that I setup in Computer Management

SUCCESS!

However, is this the route to go? Is the Directory Binding setting in Computer Management more of a legacy feature?

[bozemans]

@edullum I am experiencing the same issue in my environment. We completed 120 clients of 750 re-provisioned via DEP and discovered that the script I sent out to change the name of the clients to their serial number was not happening prior to the AD binding we set up in our configuration profiles. In looking at the configuration profile logs we noted multiple clients to have the same "computer id" of "mac-book air" and/or "mac-book air (1)" and so on while others had the correct computer ID. These computer with the same name causes issues with the AD server because it can't authenticate with the same "computer ID". When we look at the logs for the "name change" script...they are all successful. It just doesn't always happen prior the AD binding...

I see what you are attempting to do...set the "name change" and then have the AD binding take place after that...but how are to do this....I don't see a way to make sure the script policy runs prior to the AD configuration profile applying to the clients....

Yes, this seems to the be only way I can see that we get the "computer name" set prior to the AD binding taking place.

Any help/advise would be great!

[bozemans]

So, does someone have a script that will do both? First, change the name to the serial number and second bind to AD and set to create a mobile account after authentication. That would solve the issue...I think. Then we just run the script and we don't worry about the configuration profile until after we distributed to clients. Thoughts/Ideas? I'm digging for the script in Jamf Nation discussion boards, I bet someone has already come up with a solution.

[edullum]

I've made progress, thanks to the people who have chimed in on this post. I ended up creating ONE policy with three components to it, but it's still not ALL the way there yet.
First component of the policy is to add a script payload. I selected the name change script I wrote that changes the name of the Mac in three places to the serial number. I chose to run the script's priority to run BEFORE any other actions within the policy.
Second, I added a Directory Binding payload to the policy. You have to configure a directory binding in Settings>Computer Management then you can add it to the policy.
Lastly, I added an Update Inventory to the Maintenance payload.

When the policy runs successfully with a completed status in the logs, I get the following:

Executing Policy Set Computer Name Bind to AD
Running script Name Change Serial Number...
Script exit code: 0
Script result: Binding No Name to abc.org...
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 1)
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 2)
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 3)
Bound to Active Directory (abc.org)

When the policy fails, I get this:

Executing Policy Set Computer Name Bind to AD
Running script Name Change Serial Number...
Script exit code: 0
Script result: Binding No Name to abc.org...
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 1)
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 2)
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 3)
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 4)
An error occurred binding to Active Directory: dsconfigad: Node name wasn't found. (2000). (Attempt 5)
Error: Giving up on Active Directory binding after 5 attempts.

[bozemans]

I see now how you have set yours up. I'll get to testing here and see if we have similar results.

I'm still hoping for a simple/elegant script to do both.

[bozemans]

Just tested two clients: Used a script to unbind first. Then used this policy that had the "renaming" script and the AD binding set to run after the script. Worked like a charm with those two and no errors. I'm using ethernet to accomplish this task could a connection to the server be an issue? That was the same code I was getting earlier today (2000) and my IT guy told me that meant we had a connection issue.

[edullum]

Do you mind sharing your scripts? I had a thought...maybe the mac needs time to rename before it is being bound to AD...like..even 10 seconds. Maybe it's trying to bind to AD before it has been named?? Just thinking out loud. Because 3 out of 5 machines that I have enrolled have completed the policy successfully and 2 of the 5 machines have failed policies.

[jared_f]

I have not seen this issue, when the bind was failing for me, I found that we could not ping our AD server from the computer. Adding the DNS entry of the server IP fixed it. We began doing this at the network level for DNS and are pushing the configuration profile.

[edullum]

@jared_f That isn't an option for us. It's possible that the IP address could change; therefore jeopardizing the configuration profile since it is set to the DNS name. There are no known network issue here at this time to cause the machine to not reach our domain to bind it to AD.

[bozemans]

@ edullum Here is a screen shot of the settings in Jamf Pro:

Here is the script we use to set the computer name of the laptops to the serial number:

!/bin/bash

API Variables

apiUser=Admin user name here
apiPassword=Admin user Password here
serverAddress=https:address here

Get computer serialnumber

serialNumber=$(ioreg -c IOPlatformExpertDevice -d 2 | awk -F" '/IOPlatformSerialNumber/{print $(NF-1)}')

Set ComputerName using variables created above

/usr/sbin/scutil --set ComputerName $serialNumber

Set Hostname

/usr/sbin/scutil --set HostName $serialNumber

Set LocalHostName

/usr/sbin/scutil --set LocalHostName $serialNumber

Set computer name in Jamf Pro

curl -fsku ${apiUser}:${apiPassword} -H "CONTENT-TYPE: text/xml" ${serverAddress}/JSSResource/computers/serialnumber/${serialNumber} -X PUT -d "<computer><general><name>${serialNumber}</name></general></computer>"

[edullum]

Yikes...I'm not a fan of having an AD account user name and password in a script.

[bozemans]

This AD account is a "dummy" account we only use at this time of year. Otherwise, it is shut down/disabled throughout the rest of the year when we are not in the reprovision mode.

[bozemans]

So my solution is not working this morning because the binding is set up in the prestage enrollment>options>directory binding. I am going stop the binding process in the prestage enrollment. Then use a configuration profile for the binding and in the option to set the client ID use the following wildcard $SERIALNUMBER and see if this works.

[edullum]

I finally figured out a way to sync Apple Time, Name the computer, and bind it to AD all through policies. There isn't a way to set priorities to the policies. Hopefully that will be a feature in a later version of Jamf Pro. In Jamf Pro v10.5, the policies are deployed in the order of alpha-numeric...sometimes. The best way to deploy policies in the order in which you want them to, is with custom triggers. Here is how I got things to work when the machine is hardwired with Ethernet...I still have to figure out wireless, because I have a butt load of MacBook Airs that are going to be distributed and enrolled via DEP/PreStage:

1) Created Policy: 001 Sync Apple Time Server Triggers: Enrollment Complete Custom: synctime Frequency: Ongoing Restart options: default settings Files and Processes: ntpdate -u time.apple.com; jamf policy -trigger changename (This will sync computer to Apple Time Server and then run the next policy based on the trigger name)

2) Created Policy: 002 Change Computer Name Trigger: Custom: changename Frequency: Ongoing Restart options: default settings Script: Priority set to Before I added a line in the script to change the NetBIOS Name of the mac...so there is actually four places to name the mac. In my experience with this nightmare, changing the NetBIOS name is the key for end users to be able to log into the machine right after it has been enrolled via DEP/PreStage.

#!/bin/bash

# Save the computer's serial number in a variable so it can be used in the next command.
sn=$(ioreg -l | awk '/IOPlatformSerialNumber/ { split($0, line, """); printf("%s
", line[4]); }')

# Set all four OS X computer names to serial number
# Bonjour name ending in .local
scutil --set LocalHostName $sn
# Friendly name shown in System Preferences > Sharing
scutil --set ComputerName $sn
# The name recognized by the hostname command
scutil --set HostName $sn.d211.org
# Set the NetBIOS name as the serial number
defaults write /Library/Preferences/SystemConfiguration/com.apple.smb.server NetBIOSName -string "$sn"

Maintenance: Update Inventory Files and Processes: jamf policy -trigger bind (This will run the next policy in order..the bind to AD policy)

3) Created Policy: 003 Bind to AD Trigger: Custom: bind Frequency: Ongoing Directory Bindings: Configured in Settings>Computer Management (Make sure the user name and password you are using in here has the rights to put a machine on the domain. Restart options: default settings Maintenance: Update Inventory Files and Processes: sudo defaults write /Library/Preferences/com.apple.loginwindow PasswordExpirationDays -int 0 (We added this line, because as soon as an AD user logs into the Mac with High Sierra, it will prompt the user to change his or her password. Once they do this, depending on your Group Policy for password changes, the password will reset to the duration in which the password expires. For example, we have 180 days set for passwords to expire. We were experiencing the user changing their password when prompted to on the mac and then checked AD to find that the password expired in 180 days. Now, we originally had 0 days selected in PreStage under the Directory payload under Interface: Password Trust Interval; however the users were still being prompted to change it within 25 days. I played around with the setting and changed it to 25 days...then the users were prompted to change their password in 24 days. In my opinion, it's a bug in Jamf pro v10.5. We decided to take control over it by implementing the line of code above.

Scope the policies to All Managed Computers (or whatever is relevant to your environment)

In the above scenario, you could probably combine the policies into one or two, but then you are putting all your eggs in one basket. If anything should change in the directory bindings, or if your team decides to name the machines differently it can easily be edited in the individual policy without sacrificing the other policies.

If you have any of those three policies that fail on machines and you need to re-run the policy "NOW", this is what I did:

1) Created new policy: Run Enrollment Policies NOW Triggers: Custom: enrollment Frequency: Ongoing Restart options: default settings Files and Processes: ntpdate -u time.apple.com; jamf policy -trigger changename (This will sync computer to Apple Time Server and then run the next policy based on the trigger name) Scope: Add the computers to the scope of this ONE policy that needs to run the policies again

2) Open Jamf Remote, select the computers within the scope of the policy, then go over to the Advanced tab and use the Execute Command line and enter: jamf policy -trigger enrollment

I have many other troubleshooting scenarios that I have gone through, so if you have questions, please ask! Chances are I have experienced it and can help.

[Nix4Life]

@edullum

two quick questions:

1. is there a reason you are using Apple instead of a local server like your DC or onsite NTP server
2. since ntpdate is being deprecated, have you looked at SNTP?

[mkolb]

I haven't read every post now, but if the clients are already enrolled to the JSS, why not use the jamf binary tool for changing the name to the serialnumber and joining AD?

#!/bin/bash


#Change the computername to serial number
jamf setComputerName -useSerialNumber


#Variables for the Credentials to bind the client to the Directory
adadmin=""
password=""

#Check if a value is defined in parameter 4 and if so, adds it to adadmin
if [ "$4" != "" ] && [ "$adadmin" == "" ]
then
    adadmin=$4
fi

#Check if a value is defined in parameter 5 and if so, adds it to password
if [ "$5" != "" ] && [ "$password" == "" ]
then
    password=$5
fi

#This binds the client to ActiveDirectory and activates local user caching, so accounts won't get deleted after they logged in for the first time
sudo jamf bind -type ad -domain foo.lan -username $adadmin -password $password -ou OU=fooo,OU=foooooo,DC=foo,DC=lan -cache -localHomes -defaultShell /bin/bash 
exit 0

This script can be executed by a Jamf policy. You also wouldn't have to enter the AD credentials directly as they can be handed over by parameters in the policy.

Greetings,
Marco

[edullum]

@Nix4Life Using the Apple Time Server was recommended by our Jamf Support Rep.

[edullum]

@mkolb Thanks for responding. It would be a security issue in our environment to have an API user name and password in a script; therefore I had to find another way.

[mkolb]

Thats the point.. there is no user name or password in it. You can enter them inside the JSS as script parameters. If you want you can also encrypt the input there, using this>> encrypt script parameters

[edullum]

@mkolb Thanks for the info. We might do something with this next year, but for now we have found a method that works.

[#27]

I just went through this same issue, I needed to apply a config profile that bound the Mac to AD using the computer name as the client ID. Here is what ended up working for me:

1 - Configured a config profile with my AD Bind settings
2 - Set up a policy with a script to name the Mac using desired naming conventions
3 - Scope the policy to a smart group based on the serial numbers of the Macs I want to name
4 - Scope the AD Bind Config profile to a smart group of Macs with the names "Like" the desired Macs.

This allows me to be sure that the binding config profile doesn't even try to bind until the Mac is named correctly, which can then use the $COMPUTERNAME as the Client ID.

If this doesn't make any sense, feel free to ask any questions.

[djwojo]

Has anyone seen the enrollment complete trigger NOT kick off this process? I'm using jamfcloud, settings haven't changed, and all of a sudden the enrollment complete trigger just stopped working for all policies. I double checked my check in settings and they seem ok, making sure that the network state change was not selected.

I definitely have less hair since someone here caught wind of "Zero-touch." :|

[Dan1987]

Hey,
Sorry to revive an old thread but we just started our AD bind tests and have a small issue.
The bind happens successfully and the user gets a network managed account created from the login window.
My issue is that we would like Domain admins to be able to unlock preferences etc.
The group is there but the unlock doesn't work. Wo
Would this need to be changed In AD?
Thanks