Fix for missing AD security groups in Lion

A few weeks ago i ran into a weird issue on some of our Mac OS X Lion (10.7) machines. For some reason they weren’t able to see all of our security groups under the Network Groups section. I’ve verified that this issue isn’t present in Leopard (10.5) or Snow Leopard (10.6) so i’m assuming this is a “new feature” of Lion. (As of 10.7.3 at least) 

Anyways, when you open “Get Info” for any file or folder and click the plus (+) sign in the Sharing & Permissions section you’ll see what i’m talking about. Select “Network Groups” and scroll through the list:

Missing a few groups, eh?

Here’s the problem. For some reason Lion only displays security groups from Active Directory that contain the “displayName” attribute. Newly created security groups, by default, do not contain this attribute. In order to get the security group to show up properly in Lion you need to fill in this attribute with the security group’s name. 

Here’s how you fix it. Open up the security group in your favorite Active Directory editor. (I prefer to use the one built into ADUC. You’ll need to check the “Advanced Features” option under the View menu to see it.) You will find that the “displayName” attribute is set to <not set>. Let’s fix that. Select the attribute and hit the Edit button and type in the name. 

Hit okay and then apply. BAM! Go to your nearest Lion machine and you’ll find that the security now shows up properly. 

As always, I contacted Apple regarding this bug “new feature” and have yet to hear back from them. I’ve combed through Lion looking for any hints as to why this is happening. For now you’ll just have to manually set this attribute for security groups you need on Lion until Apple releases a fix. If it really bugs you i bet you could write a powershell script to set the displayName attribute of all security groups in your domain. Just keep in mind that you’ll have to set this attribute by hand for any new security groups you create. 

Update: I just confirmed that new distribution groups created from within Exchange (2010 in my case) actually do have the “displayName” attribute corretly populated. So this may just be limited to security groups created from ADUC. (2003/2008/2008r2) 

18 February Permalink

Exchange 2010 Autodiscover Issue

So the other day at work i ran into a very usual problem with Exchange 2010 and the Autodiscover service. We discovered the problem when a user submitted a ticket claiming his blackberry wasn’t synchronizing correctly. He said his email was working fine but his contacts and calendar items were not. He also mentioned that he was getting a username & password dialog box when he opened Outlook.

We tried the usual troubleshooting. The first thing we ran into was that when he would open Outlook and enter his username and password it would immediately lock his account. (Still not sure why. Could be related to this problem discussed below. Not really sure) We logged into his account from another workstation and had the same issues. Juts for fun, we logged onto his workstation with a valid test account and didn’t have any the above problems.  

One of the things we noticed when setting up his Outlook profile on the test workstation was that for some reason Outlook wasn’t able to autoconfigure his profile using Autodiscover. We tested this on a few other computers and got the same result. When we would try the same thing as a test user (or any other valid user) autoconfigure/autodiscover worked fine. The autodiscover service didn’t like his account for some reason. 

So now i went from thinking there’s something wrong with this guy’s account to there’s something wrong with AutoDiscover in general. I immediately pulled up the EMS and ran a Test-OutlookWebServices test on his account. (Test-OutlookWebServices -Identity:[username]) I got the following result:

Obviously we have a problem here. Fearing we might have a larger issue on our hands, I immediately tried the same command on a few other users and found that Autodiscover was working for most of our users but not for all. The issue only seemed to affect certain people. 

Upon examining the results of the OutlookWebServices test a bit further, one particular error stood out. “Autodiscover returned the error: 603:The Active Directory user wasn’t found.” I went straight to the source of all knowledge, Google, and looked the error up. Unfortunately there wasn’t much to be found. The two things i did find suggested that the only solution they knew of was to disable the user’s mailbox, delete their AD account, recreate the AD account, and then reconnect the mailbox. They claimed this fixed the issue but also said that they had no idea why this fixed the problem. 

Seeing as i really hate solutions to problems that offer no explenation as to WHY the problem occured or WHAT fixed the problem, i kept looking.

The first thing i did was pull up AdExplorer (ADSIEdit works too) and look at the AD account of one of the affected users. One of the first things i noticed was a key called “msExchDelegateListBL” that contained a link to several AD users that no longer had exchange mailboxes. 

Ahah! So it appears that Exchange/Outlook is trying to connect to those mailboxes even though they’ve been deleted. This is the problem! you see, our standard practice when asked to deactivate an account is to delete the mailbox but keep the AD account. I really don’t know why we do this but that’s the policy. So it sounds like Exchange isn’t cleaning up after itself when we delete or disable mailboxes. (Pesky M$ bugs…) 

To fix the problem, the first thing i tried was opening the key and removing the non-existent mailboxes. I promptly received the error “Unable to update attribute: A constraint violation occured.” After another google search i found out that the msExchDelegateListBL attribute (BL meaning back link) is linked to the msExchDelegateListLink attribute. So in order to remove the entries from the msExchDelegateListBL attribute of the current user you have to open the AD account of the user mentioned and remove the entry from that user’s msExchDelegateListLink attribute. This will remove the entry from the original user in question. 

As soon as i removed the links to non-existent accounts, Autodiscover magically started working again, the outlookwebservices test stopped erroring, the user’s blackberry began syncing contacts and calendar items and we were able to configure his Outlook profile via autoconfiguration/autodiscover. (The username and password dialog also stopped showing up.) Problem solved!

The last thing i did, to ensure that this problem didn’t exist/happen to anyone else, was an ldifde dump for all of the AD accounts that no longer have mailboxes but still exist in AD. (We move all of these types of accounts to a specific OU so it was fairly easy) I then filtered the results for any accounts that contained data in the msExchDelegateListLink attribute. Fortunately there were only a handful so I was able to go through those accounts and removed the links. 

Anyways, the main reason for writing this is to put it out there on the interwebs for others to find. I wasn’t able to find a definitive solution to this problem that both fixed the issue and explained why it occurred. I hope this post sheds some light on the problem and helps those of you who are having the same issue get it resolved. Hopefully Microsoft squashes this bug in an update sometime soon. 

15 August 3 Permalink