Archive

Archive for the ‘Active Directory’ Category

Monitoring Jamf Infrastructure Managers on Red Hat Enterprise Linux

August 23, 2019 Leave a comment

A vital component of a Jamf Pro server setup is usually its LDAP connection to a directory service (usually an Active Directory server.) This connection allows the Jamf Pro server to not only leverage the directory service’s users and groups, but also automatically populate information about the owner of the device by doing a lookup in LDAP as part of a computer‘s or mobile device’s inventory update and assist with providing user-specific policies in Self Service.

As more folks move from using self-hosted Jamf Pro servers to now having Jamf host them in Jamf Cloud, this LDAP connection usually requires an LDAP proxy in order to securely connect a Jamf Cloud-hosted Jamf Pro instance to a company’s internally-hosted directory service. Jamf provides an LDAP proxy for this purpose in the form of the Jamf Infrastructure Manager (JIM). 

Because the LDAP connection is so vital, it’s just as vital that the JIM stay up and working all the time. To assist with this, I’ve written some scripts to assist with monitoring and reporting for a JIM running on Red Hat Enterprise Linux. For more details, please see below the jump.

Read more…

Updated MigrateADMobileAccounttoLocalAccount script now available to fix password issue in macOS 10.14.4

April 5, 2019 6 comments

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. I had to update it in 2018 to fix a bug, but once that issue was fixed, the script has chugged along without changes between macOS 10.13.5 and macOS 10.14.3.

However, starting with macOS 10.14.4, I was alerted to an issue with how the script worked in combination with a change on Apple’s end.

As part of the script, the following actions take place:

  1. The password hash value of the account from the AuthenticationAuthority attribute of the relevant account is backed up.
  2. The AuthenticationAuthority attribute is deleted from the relevant account.
  3. The AuthenticationAuthority attribute is re-created and the password hash of the account is restored from the backup.

As of macOS 10.14.4, once the reference to the password hash is removed from the AuthenticationAuthority attribute, the actual password hash is now automatically deleted by the OS. That means that step 2 in the process described above actually causes the password for the account to be removed, so that the account’s password must be re-set.

How to fix this? For more details, please see below the jump.

Read more…

Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

June 16, 2018 11 comments

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. In my testing in 2016, everything seemed to work right and I didn’t see any problems with it on OS X El Capitan.

Fast forward a couple of years and a colleague of mine, Per Oloffson, began running into a weird problem with upgrading Macs from Sierra to High Sierra. When he upgraded Macs from macOS Sierra to macOS High Sierra, he was finding that Macs that had been migrated from AD mobile accounts to local accounts were having those same accounts break.

After a considerable amount of troubleshooting, he was able to narrow it down to the macOS High Sierra installer changing the password hash on those accounts. But why was it changing them?

In short, it was changing them because of a bug in my original MigrateADMobileAccounttoLocalAccount.command interactive migration script. Sorry, Per. For more details, please see below the jump.

Read more…

Disabling Jamf Pro LDAP wildcard searches to speed up user and group lookups

May 27, 2018 3 comments

When setting up Jamf Pro, one of the options you have is to integrate it with your company, school or institution’s LDAP-based directory service. Connecting Jamf Pro to LDAP allows you to query your organization’s directory service for information and also allows the use of your existing user accounts and groups when requiring logins or scoping policies.

When setting up Jamf Pro to connect to a directory service, there’s a Use Wildcards When Searching setting with the following description:

Allow partial matches to be returned when searching the LDAP directory

Screen Shot 2018 05 27 at 12 19 00 PM

What this setting does is that it allows Jamf Pro to use wildcards when making LDAP searches of your directory service. That allows Jamf Pro to return search results that may only partially match what you told it to search the directory service for.

For directory services with fewer than five thousand user accounts and/or groups, having this option enabled is usually fine. However, once the directory service is larger than that, disabling the Use Wildcards When Searching setting may dramatically speed up user and group lookups. For more details, please see below the jump.

Read more…

Categories: Active Directory, Jamf Pro, JSS

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 "\""
AD_username_here
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 36 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 2 comments

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 administrator@workstation-name.domain.org

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

The authenticity of host ‘workstation-name.domain.org (ip.address.here)’ 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.

Assumptions:

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

%d bloggers like this: