OT--Best way to handle mixed environment and AD bindings--seeking advice and prespective

kateswist
New Contributor

This isn't a specific issue, but I'd like to know from people who have experience with AD bindings and MS domains if could give us advice in the form of "if I knew then what I know now, I would have done XYZ instead of ABC".

The whole reason we bought the Casper Suite was the following (ordered by importance)

  1. AD authentication for users
  2. common network home folder location for both PC and Mac
  3. managing printers and auditing printing
  4. pushing updates & deploying software
  5. inventory

We are having a heck of a time with our bindings. It seems like half the time my mac laptops can't talk to a domain controller so they can't authenticate. It "feels" like our mac computer accounts are expiring in AD, but I can't find a place where I can confirm my "feeling" on the mac or AD side. We rely heavily on OUs in our AD for all sorts of things, and when I move a mac from one OU to the other, it doesn't seem to know or care. These are just a few examples of many issues.

I'd love to actually get to composer and deploying updates and using the MDM, but if I can't get my bindings correct so users can log on, I don't have time to look at the other stuff that Casper can help with.

I have been reading a lot on these boards that people use other things to manage the AD bindings like Centrify express, spiceworks, Admit Mac. I didn't think Casper was particularly cheap so the thought of deploying another product to deal w/ AD bindings rubs me the wrong way, since that was the main reason we purchased the product.

I'm just trying to get a feel if Casper is the best tool for my particular job.

Thanks in advance,
Katie

8 REPLIES 8

clifhirtle
Contributor II

Kate, are you able to successfully bind your Macs outside of using Casper’s built-in binding? If so, how are you binding them (via script/Terminal or by GUI/Directory Utility)?

If you have bound Macs that are working a good test would be to run “dsconfigad -show” in Terminal on the working vs Casper-bound Macs to see if there are any differences between the configuration on one Mac vs the other.

As well, there are some variables in the bind process that are simply not configurable through Casper’s standard AD bind GUI. You may have to tweak additional settings via the dsconfigad command (https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man8/dsconfigad.8.ht....

Example: in our enviroment we use the standard Casper bind, but need to tweak the vanilla AD search path to a specific domain domain (versus standard “/DOMAIN/All Domains" value). We also nix the default auto-mounting of user home shares to avoid login lag when users are off-network. There are a lot of variables that are simply not exposed by the default Casper binding UI. Having a good AD bind script is a good defense to clean up with Casper’s default bind capability cannot handle.

tkimpton
Valued Contributor II

I agree with Cliff. Step at a time, try getting a machine to bind manually with point and click then try other machines in other OU manually and confirm you get them working.

I also gave a test account and policy scoped to all machines to delete this test account at logout. This makes it a lot easier to test if it's bound to the domain, login and create the account. Hope that helps a little.

kateswist
New Contributor

@clifhirtle][/url][/url

I think I see where my main problem is after I did the dsconfigad -show. The -passinterval is set to 14 days. That must be a default somewhere that I was unaware of.

But that makes perfect sense because it "felt" like our computer accounts had expired just like the old NT accounts used to expire eons ago on the windows side of the world.

If I want to make those kind of changes, that are beyond the UI in the mac or in Casper, where can I look to for some scripting help?

clifhirtle
Contributor II

Yea that is the default value @kateswist. It may seem uber-nerdish but getting comfy with checking the manual files for commands out there is going to save you a ton of frustration (ie: "man dsconfigad"). Trust me whatever skills you can learn in the command line will more than pay for themselves down the line in boosting your OS X abilities.

Beyond that make a strong case with your managers to take the official Apple OS X certification courses at least once (http://training.apple.com/certification/osx). The core Support Essentials course is a critical deep dive into transitioning some of that existing Windows expertise to the Mac.

Consider also getting out to any of the Mac IT conferences that happen around the year. There's a great thread off MacEnterprise right now discussing the various conferences and how they compare. Not all are expensive and you'll make some great contacts.

Related: have you considered joining or starting a regional JAMF Casper user group in your area? We are just getting off the ground with one in Massachusetts and after just 1 meeting I'm totally sold on their value.

Nothing worth learning is ever easy, particularly at first, but communities like this, MacEnterprise, AFP548, and the variety of systems admins blogs are an amazing resource for getting issues resolved.

evarona
New Contributor II

@kateswist][/url][/url][/url,
@clifhirtle][/url][/url][/url is spot on with binding issues, approach and command line advice. I'll just add that I recommend AGAINST moving Macs from OU to OU, they don't seem to respond well and in my experience need to be re-bound. Search path and other variables really depend on the unique complexities of your AD environment, domain root level and even schema in some W2k3 cases. Our AD environment is somewhat straightforward; a single forest with many child domains but all user accounts are in a primary domain. That makes user auth simple.

The other tip I'll pass along is for multi-site environments. Create distinct bindings for each geo. This way you can point machines to a LOCAL DC for authentication. We had issues with east coast users not being able to log in when bound to a west coast DC. So I have a "base image" configuration with all apps, packages and scripts. Child configs add only a site assignment and AD binding specific to that location. I also have Policies configured similarly. I have a base "all sites" policy scrubbed of localized settings then assign site specific polices that include time servers, time zone and local SUS. BTW 10.8 will recognize a DC as a valid time source, at least in our environment.

The last tip, one of my all time favorites, is for pumping man pages to a PDF for later review

man -t *some_command* | open -fa /Applications/Preview.app

This will pipe a postscript formatted output of some_command to Preview where you can save as a PDF. I sync these to iCloud and regularly refer to them on my iPad, ESPECIALLY the bash man page.

Hope this helps.

lisacherie
Contributor II

@kateswist][/url

I have found the built in AD bind to sometimes be unreliable - I think this may have been due to previous defects, however we now bind to AD using a script at first run, and also by policy scoped from smart groups identifying computers with non compliant AD configs.

I would suggest asking your AD administrator to create a service account for you which does not expire with very limited privileges that only allows binding of computers. You can use this account in the script.

Here are parts of a script that might get you started, you can add additional options to configure site specific AD options for your workplace. You will also want to remove the /var/log/secure at the end of the script to avoid leaving the service password in clear.

#!/bin/sh

HOSTNAME=`scutil --get HostName`
U='your_service_account'
P='service_account_pword'
DOMAIN='your_domain'
OU='OU_for_the_macs'

echo $HOSTNAME

/usr/sbin/dsconfigad -f -a "$HOSTNAME" -u "$U" -p "$P" -ou "$OU" -domain "$DOMAIN"

For printers.. I like to have them all in self service, users can add the printers they like. I also use MCX that allows non admins to add/remove printers.

There is an option at least in the 8.x series to collect printers in inventory so you can see what printers are installed. Not sure on 9.x.

I hope this helps!

evarona
New Contributor II

@lisacherie, If you don't mind, would you share your MCX settings for allowing non-admins to add/remove printers? We're doing it all through Self Service (all users are not local admins) but I'm always looking for options. PM me on LinkedIn if you prefer. Thanks.

lisacherie
Contributor II

Try the following:

/Library/Preferences/com.apple.mcxprinting
RequireAdminToAddPrinters
False