Configuration Profile Tool

@plawrence @dan.kubley, the issue we saw was exactly as described previously in the thread. Our solution was one @rtrouton proposed herehttps://derflounder.wordpress.com/2013/11/13/bypassing-the-mavericks-managed-preferences-login-check/. We have, however moved to some Yosemite testing and found that this solution no longer works. We have not as yet, had a chance to troubleshoot, but will report back when timing allows.

@dan.kubley, have you seen any internal solutions to this issue or have you been able to reproduce it the way @plawrence described. We are still seeing this exact behaviour. Cancelling will clear the nag for the current session but any subsequent sessions are prompted again with the Configuration Profile Tool message. If local admin credentials are used it does completely remove the profile/s.

@mfcfadmin

Thank you for checking back in on this. Are you by any chance binding computers to AD and mapping the UID and GID attributes in the binding? We have reports of this causing the issue so far from one customer. We are working on trying to replicate it here internally at the moment and should have an update fairly soon.

@mfcfadmin

As Dan mentioned, the cause of our 'Configuration Profile Tool' issue was due to us mapping UID and GID attributes within the Active Directory binding. Once we removed those the error message disappeared, it seems as though the mdmclient process was unable to identify the user logging in if those mappings were configured.

Hey @mfcfadmin,
After a bit of testing internally, we were unable to replicate this issue in any form. We also attempted the UID and GID mapping like @plawrence described, but due to our AD being set up differently, all that resulted in was a broken AD binding. Sorry that we have not been able to provide further information at this time.

@dan.kubley, thank you for the follow up. We were able to remove the mappings and as such alleviate the Configuration Profile Tool pop ups. Though not ideal it has stemmed the tide.

Thanks again.

deleting the "Active Directory" keychain entry under "System" prompted for a new local items password, once the password was changed for local items (to current password) then restarted the computer. It fixed all the keychain issues including configuration tool prompt.

@khurram the "Acitve Directory" entry in the System.keychain?

Hello, I have been working on this extensively with JAMF and Apple Engineers, currently running OS X 10.10.3 with JSS 9.72. I have a number of Macs that are fiber attached to a SAN with Volumes mounted. Some are on OD and some are on AD (we are migrating from OD to AD). The solution that I came up with to remedy file permission issues being a nightmare during the transition from OD to AD, was to install the Linux Extended Attributes extended schema in AD. This allows users to be assigned UIDs and GIDs within AD. Then in OS X AD client, you can set mapping properties to map the UID, GID, & GGID to the attributes in AD that tell OS X to generate the UID/GID based on the AD attributes instead of dynamically generating the UID/GID per user. I'm running Windows Server 2008 R2 as my DC so the attributes I map to are UID=uidNumber, GID=gidNumber, & GGID=gidNumber. This ensures that you have consistent UID/GIDs globally across your machines so when a user creates a file/folder on the shared SAN from one computer they can read/write that same file/folder from another computer on the SAN because the UID/GID associated with that users log in is the same across the network. With network accounts, using this ID mapping tool within OS X breaks MDM, subsequently causing the popup box everyone is talking about, it's caused by specifically the UID mapping attribute. Apple knows about this issue, and has a team of Engineers working on it with no expected turn around time, or at least they won't share it.

The work around:
Mobile accounts! By choosing to create mobile accounts and have them auto create when a user logs in to the machine for the first time, go into the System Preferences --> Users & Groups --> Login Options --> Edit Network Account Server --> click "Open Directory Utility" button --> click the lock & authenticate --> double click "Active Directory" --> click the grey arrow to expand the menu. This is also where you would set up your ID Mappings under the "Mappings" tab. Now, under the "User Experiance" tab tick the box "Create Mobile Account at login" and uncheck the box "Require confirmation before creating a mobile account". Click OK and back out of System Preferences. Done.

Caveat to the work around with another work around:
Each time a new user logs in while mobile accounts is enabled, the Apple Setup Assistant will run and ask the user if they want to encrypt their hard drive and also ask them if they want to sign into their Apple account (iCloud account), etc. To disable the Apple Setup Assistant from running I found a someone (rtrouton) who built a handy script for this which works quite well. Link to Script. I just copied this script into my JSS and ran it on machines that will be using mobile accounts and no more setup assistant!

Note:
If you did not previousl;y use ID mapping and just turned it on, your users that previously logged into a machine will no longer have access to anything locally as their UID/GID has changed. You can either try to chmod/chown their entire Home directory but this does not always work. I just wipe their local home directory as it will be re-created once the user logs back in.

Great stuff, @ZachB ! Thank you for sharing this with the community.

Official Fix (not just a work around)

So, my previous post explained how to create a work around which works quite well. Here is the official "fix". You will need access to the AD domain controller or you may have to buy lunch for your domain admin. You will need to log into your AD domain controller as a Schema Admin user.

Explanation of the Problem:
When an AD user logs into a Mac OS X machine that is AD bound, OS X sends a query to the AD server requesting information about the user. If ID Mapping is configured on you OS X image, that will also be part of the query. The query is made to the AD Global Catalog and by default, the uidNumber & gidNumber attributes are not replicated to the global catalog and therefor not returned to OS X as part of the query payload when a user logs in. For some reason, not explained by Apple, this will cause the MDM to unload breaking your configuration profiles that you have worked so hard at configuring.

Walk through:
Once I discovered the resolution, I created an internal KB article for my group, I will just paste it here;

By default the uidNumber attribute is not replicated to the Global Catalog in Active Directory. When signing into the account from OS X, OS X will submit a query to search for the user’s AD record, but the AD server does not include the uidNumber attribute in the response. This leads to the removal of the MDM payload during the initial MDM status check after login. Once the uidNumber attribute is set to replicate to the Global Catalog, users will be able to log in from OS X without triggering MDM payload removal.

Here is the procedure to enable the uidNumber attribute to be replicated to the Global Catalog. This only needs to be done on the Master Domain Controller as all other DCs that replicate from the master will inherit these settings.

1. On the Master DC go to Start --> Run and type in “regsvr32 schmmgmt.dll” (without the quotes), then press enter. You will get a popup validating that this feature has been enabled.
2. Open MMC and add the Active Directory Schema snapin.
3. In the console tree, click Attributes.
4. In the details pane, right-click the attribute that you want to edit, and then click Properties.
5. Check the box that is labeled "Replicate this attribute to the Global Catalog".

In a small AD forest this should propagate pretty quickly.

In addition, I have found that it is a best practice to follow this same procedure for the "gidNumber" attribute. This will unsure that the uid/gid will properly resolve when viewing file permissions or when using the ID command in terminal.

Note: If you are denied the change because of insufficient privileges, make sure the user you are logged in as is a member of the "Schema Admins" group in AD.

Helpful Links:
1. Indexing in Active Directory
2. OS X, OS X Server: Active Directory attributes required to be accessible to OS X computer account objects