active directory profile manager

You don't use Profile Manager to allow AD users to log in. You 'bind/join' the Macs to your Domain using the built-in tools on the Client OS (the workstations) to do this just as you would when joining your PCs to the Domain.

On your client Mac workstations:

Log in as the local administrator

Click on the System Preferences icon

Click on the Users & Groups Preference Pane

Click the lock and supply the local administrator's name and password

Click Login Options

Where it says "Network Account Server" click the Join button

Key in your AD Domain details. eg: myaddomin.com

Now click OK. When prompted key in the AD account name and password that has authority to join workstations to the domain. Do this for all your Macs in turn. If you have a Mac deployment tool you can automate this in the same way you would with SCCM when 'pushing' out your Mac image

Some key points for you to remember:

DNS is fundamental to this working successfully. Avoid the use of .local for the TLD of your domain. If you're already using it then expect random problems. Your PDC must resolve on both pointers Avoid the use of overly restrictive proxies as these can hamper a users working experience on Mac workstations. When an AD user logs in they will have access to their home folder as it exists on the AD Domain but a 'Mac' home folder will also be created locally so they will need to be trained not to save data to that folder. Bear in mind most AD administrators organise user home folders by nesting them inside other folders. For a user to login successfully on a Mac there must be at least Read Only/View rights all the way down to that particular user home folder.

Yes I understand that but you can't join the Macs to the Domain this way

Hey all,

This is possible with most MDMs, including Profile Manager. However, there are some foundation requirements that need to be met. They include: (1) a properly configured AD domain with the proper SVR records. Manually binding a test device to the domain will prove out the presence of the records and give you an understanding of the process. (2) Access to a user with domain binding rights. It is best not to use the domain admin account as you are embedding the credentials into the profile. Best recommendation is to create an account with limited rights. The account should be able to create, modify, and delete computer records in the targeted OU. (3) Access to a mutually agreed upon network time server. If the Mac and the Windows domain server does not agree on time, you users will not be able to login. Domain login uses a technology called Kerberos and Kerberos is time sensitive. (4) You must be using on-prem AD with a Directory payload. Azure is not supported with this payload.

There are other configs but this will get you through the basics.

If you are using Profile Manager (gasp), you can look down the sidebar for the Directory payload. Select it and switch to Active Directory as the directory type. Complete the form and make sure you are enabling the "Create mobile account at login." Leave require confirmation off or else you will be explaining over and over to allow. Don't both with the AD Certificate payload. You likely do not need it.

Setting the Directory binding for AD will allow the login of domain accounts to the Mac as well as respecting password expiry at the login window. (Check Apple School Manager for some new news regarding new features with directory integration for schools)

When the students login, they will create a cached mobile accounts on the device. This means that if Student A logs into Computer 1, the student gets a home folder titled studenta on that computer. If the same student comes in the next day and sits are Computer 6, that student will create another, empty home folder on computer 6. The home folders do not follow the students unless you pursue network home folders. But this is not advisable unless you have the right infrastructure and know the limitations of network homes (basically that Apple barely supports them and apps are not really developed to take them into consideration). They are possible, even with AD accounts, but that ship has sailed and you will be building infrastructure that likely will not have a long life.

Bottom line. You can bind to directory systems using an MDM, including Profile Manager. You need to work with your AD admin to get the infrastructure right. This is an effective way of implementing single sign on across devices for domain resources.

Good luck. Don't touch every machine. Be efficient and tell your boss it was a lot of hard work.

Reid Bundonis

Carbon Technologies

What value did you populate the Client ID field with? If you are using a fixed value, only the first device to receive the profile will be successful. The Client ID is what becomes the name of the computer record in AD. If you dropping in a fixed string, then each machine will try to bind to the domain using the same Client ID. This will cause a headache.

Use a variable in the field instead. %SerialNumber% or maybe %ComputerName% if you have no spaces, special characters, or exceed 15 characters. Since your computer name might not be curated, use serial number as I believe Apple's max characters in a serial number is 12.

At this point, I am guessing. Without screen shots I can only speculate as this is a common omission.

Now, there is also a long short that you cloned the devices in the lab. If you did, you have replicated the Local KDC. That too can cause issues. I am guessing it is the Client ID though.

Reid Bundonis

Carbon Technologies