How are you handling Directory Bindings?

We are binding using a script that makes a web request to an internal database based on the serial number of the machine and then uses the results to determine the computer name and any other details as required. You have to have a fairly accurate hardware database to start with otherwise it would require quite a lot of work to implement.

I built a script/app that prompts the user for their AD username and password at netboot/imaging time. They enter in their creds, we verify they are able to add machines to AD and are allowed to image/re-image. Then we look at the IP address the machine has and try to determine the site code in AD, if we can't find the site based on the IP/subnet range we pop up a box where the user can then enter in their AD site code manually, then we use this site code information to query a database for building, level and room information - the user is presented with popups to select this information for the computer they are imaging. Once we have all that we then run a dsconfigad script to bind the machine and put it into the appropriate OU, we also copy the user, building, level, room info into the ARD fields for inventory purposes. I have an example of all this up on https://github.com/hunty1/strapper
For that particular example, we are not using casper - but there is no reason you could not take that further, you could for example once you have determined the OU for that machine from the user supplied information, save that into the JSS, have your preflight imaging script/app/whatever query the JSS via the API to see if it has an OU on record for the machine being imaged if so then use that use that OU to bind.

I've faced this at a few companies. The solution is as the others have said, script / automate it. You could read location info from the JSS using the API and add it to the relevant OU.

In most cases though we don't see any real use for spending the time on it. Macs don't use group policies and so being in specific OUs doesn't have any useful purpose. After a cost / benefit analysis we have always decided to create a single OU for the Macs.

Can often depend on the AD team and what they want, sometimes they're not too impressed with 30k machine records going into a single OU.
There might not be any useful purpose on the Mac side of things, but theres often reporting and analytics done from the AD side, ie breakdown of machines at each site for example. Yes you could get this info from the JSS, probably be more accurate as well. But larger orgs often have their own reporting systems in place.

We have two angles here:

1) Scripts that run periodically on the DCs which automatically move computers into the proper OU based on computer name (our naming standard can be parsed to determine what type of computer it is and where it is located)

2) Binds are handled by a standalone app I built a few years back. It requires the AD credentials of the tech performing the bind, the asset number, and the site code for the office location. Everything is automated from there for consistency and ease of use via dsconfigad scripting. We have a couple hundred OUs.

We don't have as many, but we are getting to the point you are talking about. I think we need about 60 to 80 different OU's.

What we have decided to do is create 80 different bindings and create 80 different configurations, each of which is tied to a binding. At first this seems like to much work, and it is a lot of work. But there is a hidden benefit to doing this that we are hoping to take advantage of.

The fact that we will have 80 different configurations, one for each department means that each department will be able to add items into their own configuration on top of their AD binding. That way we can get more local admins in the mix of creating custom configs for their users. We will also have them all setup so that central IT can image a machine for a department and use the same config as the local admin.

The other benefit we see in this is that we will be able to ( hopefully ) pre-configure the Sites. Though this is going to be more of a challenge.

Since we don't have a database of machines and can't maintain all those configurations, we decided to go with a script that reads in the computer name and based on the 6 character prefix (3char building, 3 char department), the script can determine what OU the machine goes to.

This method still requires we maintain a "database" or "list" of mappings, but version 2 will be to break that part out into a csv or something similar so that our SCCM guys can use it too.

You can do the initial binding to one OU for all computers and then move to the correct OU via a script.
In the script you put the logic to determine where it should go.

We use adtool http://gp2x.org/adtool/ and a simple bash script to do this.

e.g. -

#!/bin/bash
##################################################################################
# Move computer to different OU
# Computer has to be bound to AD first
# adtool needs to be installed prior to run this script (http://gp2x.org/adtool/)
##################################################################################

#ADBINDUSER - AD Username to do the AD Bind.
#ADBINDUSERPASS - AD User's Password to do the AD Bind.
#CORRECTOU - OU which Computers should go into.

COMPHOSTNAME=$(scutil --get HostName)

# To do LDAPS we need to specify what checks to perform on server certificates in a TLS session. Otherwiese cert will not be trusted and can not search.
# Allow the session to proceed normally if no certificate is provided or if a bad certificate is provided
/usr/bin/sed -i "" 's/^.*TLS_REQCERT.*/TLS_REQCERT     allow/g' /etc/openldap/ldap.conf

/bin/sleep 5

# Move to correct OU (e.g. "OU=OSX,OU=Finance Dept,OU=Our Computers,DC=AD,DC=MYCOMPANY,DC=COM")
CORRECTOU="OU=OSX,OU=Finance Dept,OU=Our Computers,DC=AD,DC=MYCOMPANY,DC=COM"

# ADTOOL OPTIONS
# ?H uri - The uri of the Active Directory server to connect to, eg. ldap://ad1.example.com.
# ?D binddn - The distinguished name of the user to bind to the server as, eg. cn=admin,ou=usrs,dc=example,dc=com.
# ?w password - The password to authenticate with.
# ?b searchbase - The distinguished name of the base for any operations that involve searching the directory, eg. ou=users,dc=example,dc=com.

/usr/local/bin/adtool -H ldaps://ad.mycompany.com -D "CN=ADBINDUSER,OU=Service-Accounts,DC=AD,DC=MYCOMPANY,DC=COM" -w "ADBINDUSERPASS" -b "OU=Our Computers,DC=AD,DC=MYCOMPANY,DC=COM" usermove "$COMPHOSTNAME" "$CORRECTOU"

exit 0

Pardon my ignorance @Kumarasinghe, but what are the benefits of this approach? The way I see it, all it's really doing is adding another step and relying on another tool as the same logic is needed to move the computer to its proper OU. Am I missing something?

For us OU didn't move for existing computers even we specify a new OU in binding.
e.g.- computer1 is already in AD and we are re-imaging and binding it to a different OU. The new binding doesn't move the computer1 from previous OU as it was already there. It will bind to the same old OU even if you specify a new OU.

You can have one binding for all computers then scripts to do the OU move if you use adtool.

Thanks

@Kumarasinghe, i'm guessing that the binding account didn't have the correct permissions to the OU you were binding too.. or you had the wrong syntax for the container.

Only saying that, as it works well for me.

@bentoms][/url][/url
Can you test this (at imaging):
1) Bind a machine to OU=A and confirm it is in correct OU in AD
2) Rebind the machine to OU=B with the same computer name.
Then see the computer object in AD if it has been moved to OU=B

We have the permissions and OU is right. If we bind a non existing machine it will bind fine.
What we use is the Casper binding policy at imaging.

You will be fine if you have a script with ldapdelete or dsconfigad to delete the computer object first then bind it to the new OU.

@Kumarasinghe, ok that's normal. (Sorry I didn't fully read your earlier posts).

The computer will bind to the existing object, be it a Mac or PC.

That's why we currently have a single OU for allmacs globally, well that & the fact that we had no business need for them to be anywhere else