Archive for the ‘Active Directory’ Category

Identifying which Active Directory account is logged into Enterprise Connect

April 12, 2017 5 comments

As more Mac environments move away from binding Macs to Active Directory and using AD mobile accounts, and towards using local accounts in combination of tools like NoMAD and Apple’s Enterprise Connect, it’s become more challenging to identify which people are logged into which computers. While mobile Active Directory accounts will use the username and password of the person’s AD account, there is no such certainty with local user accounts.

Fortunately, my colleague Joe Chilcote recently let me know that it’s possible to query the logged-in user’s login keychain and get the username of the Active Directory account which is logged into Enterprise Connect. This can be accomplished by running the following command as the logged-in user:

/usr/bin/security find-generic-password -l "Enterprise Connect" $HOME/Library/Keychains/login.keychain | awk -F "=" '/acct/ {print $2}' | tr -d "\""

That should produce output similar to that shown below:

computername:~ username$ /usr/bin/security find-generic-password -l "Enterprise Connect" $HOME/Library/Keychains/login.keychain | awk -F "=" '/acct/ {print $2}' | tr -d "\""
computername:~ username$

It’s also possible to leverage this technique to update the User and Location section of a particular computer managed by a Jamf Pro server. For more information, see below the jump.

Read more…

Migrating AD mobile accounts to local user accounts

December 21, 2016 20 comments

One of the practices that has historically helped Macs fit better into enterprise environments has been to bind Macs to Active Directory (AD) domains and use AD mobile accounts, using either Apple’s own AD directory service plug-in or a third-party product like Centrify. However, this practice has meant that the password for the mobile account is being controlled by a service located outside of the AD-bound Mac. This has led to problems in the following areas:

With the recent availability of tools like Apple’s Enterprise Connect and NoMAD, it’s now possible to provide the advantages of being connected to Active Directory to your Mac without actually having to bind your Mac to an AD domain. This has led to more environments not binding their Macs to AD and using either Enterprise Connect or NoMAD with local accounts.

With local accounts, all password management is done on the individual Mac. This means that problems with keychain and FileVault password synchronization are vastly reduced because the password change mechanism for a local account includes updating both the keychain and FileVault 2 automatically with the new authentication credentials.

For those shops that have been binding their Macs and using mobile accounts, but want to switch to the new local accounts + Enterprise Connect / NoMAD model, there is an account-related challenge to overcome:

How to transition from an AD mobile account, where the password is managed by AD, to a local account, where the password is managed by the individual Mac, with the least amount of disruption for your users?

To assist with this process, I’ve developed a script that can take an existing AD mobile account and migrate it to being a local account with the same username, password, UID, and GID. For more details, see below the jump.

Read more…

Using DeployStudio as an Active Directory domain migration tool

November 27, 2013 1 comment

As part of a domain migration project, I was recently tasked with figuring out a way to handle migrating the Macs from one AD domain to another. I had the following requirements:

  1. Unbind the Mac from the old AD domain
  2. Bind the Mac to the new AD domain
  3. Migrate the user’s data from the old AD domain to the new AD domain

Preferably, it would be a procedure that anybody could use. That way, anyone on the team could be perform the migration process regardless of their personal skill level with Macs.

I had a pre-existing interactive script that I could modify and use to fulfill requirement 3, but I needed a way to fulfill requirements 1 and 2.

With some help from DeployStudio, I was able to develop an unbind / rebind procedure that fulfilled requirements 1 and 2. It also gave me the following features:

  1. Anyone on our helpdesk team could do it, regardless of familiarity with Macs or Active Directory.
  2. Potential for human error was minimized
  3. Reboots (generally a good idea when making directory service changes) were a built-in part of the migration process.

For details, see below the jump.

Read more…

Force unbinding with dsconfigad without using an Active Directory admin account

October 9, 2013 4 comments

While developing a process to make it relatively easy for a someone with little Mac experience to unbind and rebind a Mac to an Active Directory domain, I ran across an interesting problem.

I wanted to use Apple’s dsconfigad tool but it wants to have a user account and password either specified as part of the command, or have the command specify a username and it will then prompt for the password. Since I was going to be scripting this, that meant that I would need to put the password in the clear.

While I was puzzling in IRC over the issue of a) putting an AD admin password in the clear for anyone with access to the script or b) attempting to remove the binding files and deal with the issues there, Tim Sutton asked a simple question: “Did you try giving a bogus user?”

No. I hadn’t.

As it turns out, if you’re forcing an unbind, dsconfigad only cares if you give it a user and password. It apparently doesn’t care whether the account actually exists in AD. Running the following command with root privileges will work fine to force a Mac to unbind from AD:

dsconfigad -force -remove -u johndoe -p nopasswordhere

Screen Shot 2013-10-09 at 5.01.39 PM

Note: Running this command will only unbind the Mac. It does not remove the computer object from your Active Directory domain.

Diagnosing AD binding problems from the command line

March 29, 2012 6 comments

Every so often, a user may call the help desk to report that they can’t log into their Mac using their Active Directory account’s username and password. Here’s a way to diagnose remotely if their workstation is having an AD problem and needs to be re-bound.

1. Use SSH to remotely connect to the Mac in question: ssh

This message may appear if it’s the first time connecting from your workstation to the remote Mac:

The authenticity of host ‘ (’ can’t be established.

RSA key fingerprint is 47:15:1f:e0:b1:dc:05:25:2c:cf:ae:aa:8c:ac:83:c3.

Are you sure you want to continue connecting (yes/no)?

Enter yes when prompted and hit Return.

Read more…

Active Directory home directory lookup AppleScript now updated for 10.7.x

November 15, 2011 2 comments

A while back, I had posted an AppleScript that Peter Bukowinski and I had built to provide an easy-to-use way to look up the location of an Active Directory home folder. With the changes to the Active Directory plug-in on Mac OS X 10.7.x, the script also needed to be updated so I’m posting the updated script and code. The script should be usable on AD-bound 10.6.x and 10.7.x Macs, and Peter has added some new functionality to display the correct fileshare connection information for both Macs and Windows boxes.


In order to work correctly, the script needs for the Mac to be bound to an AD domain. The AD-bound Mac also needs to be connected to the AD domain via a domain-reachable network connection or via VPN.

Using the script:

Launch the script and provide the username in the blank provided, then click OK.

The home folder’s address will then be displayed in a dialog box, with the correct fileshare information for both Windows and Mac. You’ll also be prompted to copy the home folder information to the Mac’s clipboard for pasting (if needed.) Click OK to dismiss the dialog without copying the information. Clicking any of the buttons will quit the script.

As before, it should be pretty generic but the only location I’ve tested it at is here at my workplace. If you’re planning to use it on 10.7.x AD-bound Macs, check the code as you will need to make some edits.

Click here to download the script

Click here to download the source as a PDF document

Displaying expiring password notifications when using FileVault 2 with Active Directory accounts

September 12, 2011 4 comments

Due to the way that FileVault 2 handles logins, with the user logging in at the pre-boot login screen and then brought directly into their account, users with Active Directory accounts will not get the password expiration warning that normally appears at the login window.

If you need to have those notifications in your environment, Peter Bukowinski’s ADPassMon is a great freeware utility for showing your users how long they have until their AD password expires. It launches and runs after the user logs in, so it’s unaffected by FileVault 2’s handling of the login process.

For complete information on this utility, see the ADPassMon product page.

%d bloggers like this: