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 4 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 32 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…

%d bloggers like this: