Casper Imaging AD Binding

[BigToeKnee810]

So I have set up an AD bind in Casper Imaging, but binding never seems to work automatically. We can, however, do this manually through Directory Utility. Also, I cannot create a policy and use that to bind to the domain through push or Self-Service.

To give some insight here is our enviroment:

.local domain
Cloud JSS (uses read-only domain controller for user accounts)
Local JDS (Mac Mini)
Local Imaging box (Mac Mini)

Is it possible that our cloud instance is actually trying to bind to the domain with the credentials we use to connect our RODC to the JSS? Since its Read-Only is that causing the bind not to work?

[MacSysAdmin]

Make sure that your Computer OU is in an x.500 type order OU=NAME,OU=NAME,DC=WHATEVER,DC=LOCAL and that your Domain is FQDN DOMAIN.LOCAL.

[blackholemac]

I've been noticing my AD binds haven't been to reliable lately with Casper Imaging...this isn't so much a "me too" post as it is me sharing what I had planned to do when I get time...

I created our AD bindings long ago (3-4 years ago) when we set up our JSS. I was wondering if I created brand new fresh bindings by hand and uploaded them fresh if that would fix anything. I've been too lazy to try that personally as I've been dealing with other important issues. It may not do a doggone thing, but it's the first thing I'm going to try when I get time. If that doesn't work it's time to dive into log files for me.

[johnklimeck]

Binding to AD as part of the Casper Imaging process, is and can be tricky, and it often times will just not work.

I have found that things like this are better off happening after the imaging process is complete, and before the login window appears.

Things like AD binding, Login windows preferences (show full username and password), Search Domain settings, etc.

But, how does one do that?

Ah ha, enter Rich T's, First Boot Installer. Just google it, you'll find it. It will suppress the login window and install things, runs scripts (policies) before the login window appears.

Instead of doing a lengthy First Boot Script, which can change over time, and is very hard to diagnose if / when something is failing in the script, First Boot Installer uses a principle where a "payloadless" PKG is installed, and then run. Payloadless means no app, just a script (postinstall) from Composer, and that script is: sudo jamf policy -event <the-name-of-the-policy>.

You create a policy in the JAMF (server), an it consists of all the separate scripts you want to run, AD binding, Login window settings, Search Domain settings, HD name rename, etc. Whatever you want. You can also put in some packages here, like "caspercheck" (Rich T).

(AD binding being a script using the dsconfig command and switches, to me is a preferred way to AD bind (if you must AD bind). If it works once in the script, you know it will always work, run as a policy, etc.)

When the Mac reboots in Casper Imaging, and after the black curtain or Adobe Temp Install Account (which JAMF says they will fix and call JAMF Temp Account, someday, hopefully in JAMF Pro 10), you get a log window (the Login window) is supressed, this is where First Boot is working, let it work, it reboots. The Mac is at the login window, and bound to AD, done. No more anything to do, give the Mac to the user.

Now AD binding, to bind or not to bind, that is the question. There is the trend happening latley to go in the direction of not binding to AD and using things like Enterprise Connect or the free Nomad.

I can see a time soon, when many forgo the need to bind to AD, and use this approach, still ensuring a Kerb ticket to get to any AD services, servers, etc. We have been using Enterprise Connect for months now and its great.

Any further questions on the AD binding, let me know, john

[BigToeKnee810]

The only reason we bind to AD is for network accounts. We are currently looking into not using those anymore since we have recently deployed Enterprise Connect. But that maybe quite awhile down the road.