Configuration Profile Tool

[justinworkman]

I'm doing my first image testing with Lion. Imaging goes OK, but when a network(OD) user logs in they get a prompt for administrator credentials from the Configuration Profile Tool. Anybody know how to stop this?

[nextyoyoma]

Did you ever find a solution to this? My users intermittently have this issue, but not always.

[leegalan]

I'm experiencing the same issue. Any ideas?

[steventhemacman]

We are having the issue randomly as well....

[achand]

Same issue here.

[easyedc]

Same here.

[CS_MC]

And here too.

[Joel_Peasley]

Hey all,

Just wanted to get a little more information regarding this thread. When the Configuration Profile Tool pops up on a client machine are we seeing anything in regards to, "keychain is MDM_Connect"? If any of you have a screenshot of this message that would be very helpful as well.

Thanks,
Joel

[CS_MC]

Yes. Here is my screenshot.
external image link

Some more background. In my case, It doesn't happen immediately after imaging. It happens as soon as I manually install a mobileprofile that was exported from JSS. I also noticed that immediately after canceling this prompt (since no password seems to work), that I will see repeated failed attempts to remove this profile from my machine in the system.log file. I figured that perhaps Casper was trying to remove it since it wasn't scoped to that machine. I even deleted the profile on the JSS, but the prompt and errors still persist.

Here is the error that repeats over and over again:

Mar 13 11:30:20 mcmacimg02.local mdmclient[540]: ** ERROR ** [Agent:2081286642] ################################### Mar 13 11:30:21 mcmacimg02.local mdmclient[540]: [Agent:2081286642] Processing server request: RemoveProfile for: <User: 2081286642> Mar 13 11:30:21 mcmacimg02.local mdmclient[540]: [Agent:2081286642] Removing profile: [Redacted](347E6B74-71E7-4236-BD05-6D50692C3ED5) for: <User: 2081286642> Mar 13 11:30:21 mcmacimg02.local mdmclient[540]: ** ERROR ** [Agent:2081286642] ### Errors while processing: RemoveProfile ### Mar 13 11:30:21 mcmacimg02.local mdmclient[540]: ** ERROR ** [Agent:2081286642] <MCMDMErrorDomain:12013> Cannot remove profile '347E6B74-71E7-4236-BD05-6D50692C3ED5' because it was not installed by the MDM server <MDMClientError:96>

[daniel_behan]

Check to make sure that your end user keychain password matches their login password. I've seen this with cached AD accounts.

[wyip]

I'm seeing this as well.

external image link

I am indeed using cached AD accounts, and verified the keychain password matches login password. Any other ideas?

[jhmoon]

*bump* We're seeing the same issue on occasion. We've verified keychain+login as well... any help would be appreciated!

[dan_kubley]

We wanted to provide an update on this issue. We started seeing clients report this last fall, though we have not noticed it here in normal testing. We looked into this deeper, and can confirm that a temporary keychain is created anytime a push notification is sent to the device. You can see this pretty easily by unloading "/System/Library/LaunchDaemons/com.apple.mdmclient.daemon.plist" and then running "/usr/libexec/mdmclient daemon" in Terminal.

After that, send a push notification to the device and you'll see the keychain get recreated for about 10 to 15 seconds. If by random chance you put your laptop to sleep while you're in the middle of a push notification, then you'll get this prompt when you open your laptop back up. We do not have a fix at this time, but users can just click Cancel and nothing bad will happen.

We reported this to Apple last fall, under RADAR #12634896. This RADAR is still reported as Open as of today, so we do not know when a fix will be in place.

[josaxo]

Was a solution ever identified for this?

[dan_kubley]

Thank you for checking in. The RADAR is still open as of this point, and we are still investigating this issue with Apple. There is no workaround, other than instructing your users to just click the Cancel button and ignore the message. Sorry for the inconvenience.

[jbestine]

Bump. Getting this message too.

[mm2270]

We get it randomly as well. As long as it doesn't happen regularly, it seems like little more than an annoyance. The explanation above from JAMF employees is satisfactory to me. Its not their issue to fix, but Apple's. We've just instructed our users on what causes it and just to click Cancel and move on if they happen to see it. Seems good enough for them.

[kirkmshaffer]

@dan.kubley - just checking in on this to see if A) people are still having this issue, and/or B) if the RADAR has been addressed by Apple.

[dan_kubley]

Thank you for checking back on this issue. We have seen a big decline in people reporting this issue, so whether it is something Apple fixed in one of the Mavericks releases, or maybe people are just used to ignoring it by now, we are not sure of the reason. Looking at the RADAR, it is still in the open status with Apple. If anything changes, we will be sure to let the community know.

[kirkmshaffer]

Thanks Dan - we actually just started hearing reports of this here. FYI we're using 8.73 with OS X 10.9 hosts (there's one thing we're waiting for in 9.x before we upgrade).

[glynn]

To confirm Dan it is still out there and I have had the CPT issue through Lion, Mt Lion and still in Mavericks 10.9.2 as well. I think people are just ignoring it at this point or have tried their best to work in a script to try and suppress the CPT popup. We have done this at our school district with limited success. Reported Apple Bug Report about it back in February. I also referenced your previous radar#.

[mfcfadmin]

We are seeing similar pop ups, however they are occurring on EVERY network account login.

external image link

Has there been any new developments on the RADAR from Apple or has someone come up with an effective script at neutralizing this annoyance?

[dan_kubley]

Hello all,
I wanted to provide a bit of an update on this issue with the MDM_Connect prompt. Apple has contacted us about RADAR 12634896 and indicated that this behavior should be fixed now in Yosemite. The wait has been a bit long, but this sounds like good news to me! Thank you for your patience.

[plawrence]

@mfcfadmin

Did you ever figure out what was causing the "Configuration Profile Tool wants to make changes" popup on network login? I am seeing this on 10.10.1 clients, they report the following error when network users try to login:

mdmclient[5139]: [Agent:1234] Current user is not bound by the MDM configuration: '<Payload: JAMF Manual Enrollment Payload: MDM (00000000-0000-0000-A000-4A414D460004:00000000-0000-0000-A000-4A414D460004) from profile: MDM Profile (00000000-0000-0000-A000-4A414D460003:00000000-0000-0000-A000-4A414D460003)>' because it was installed by a different user on the system.
mdmclient[5139]: [Agent:1234] Removing obsolete MDM profile: MDM Profile (00000000-0000-0000-A000-4A414D460003:00000000-0000-0000-A000-4A414D460003)
mdmclient[5139]: ** ERROR ** [Agent:1234] ([HaveError] Getting ODRecord for uid: 1234 <InternalError:1> CallStack: (
mdmclient[5139]: ** ERROR ** [Agent:1234] Removing profile: MDM Profile (00000000-0000-0000-A000-4A414D460003:00000000-0000-0000-A000-4A414D460003) (Error Domain=CPProfileManager Code=-208 "This user is not allowed to add or remove configuration profiles." UserInfo=0x7fc0caf04e10 {NSLocalizedDescription=This user is not allowed to add or remove configuration profiles.})

[plawrence]

@dan.kubley

I am looking for any additional information regarding this issue. Our setup consists of 10.10.1 clients that login using Active Directory credentials to Network Home Directories. Every time a non-admin network user logs into these clients a prompt appears stating "Configuration Profile Tool wants to make changes". Users can click Cancel and the prompt disappears, but it comes back at every login. If you enter an admin username and password into the prompt, it removes the MDM profile from the client machine.

Are there any suggestions on troubleshooting this issue further?

[dan_kubley]

@plawrence

Sorry to hear of the difficulties with the Configuration Profile Tool. The issue that you are experiencing now is different from the original issue in this discussion. The original dealt with the keychain when the MDM process was interrupted with the machine going to sleep. That issue is what the RADAR was filed for, and Apple has fixed that issue with Yosemite.

I have escalated your case internally here so we now have more resources investigating it. Your support specialist will be reaching out with more information shortly.

[mfcfadmin]

@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.

[mfcfadmin]

@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.

[dan_kubley]

@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.

[plawrence]

@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.

[dan_kubley]

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.

[mfcfadmin]

@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.

[khurram]

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.

[bentoms]

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

[ZachB]

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.

[dan_kubley]

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

[ZachB]

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 ob...