Video Screencast Help
Search Video Help Close Back
to help
Not able to make it to Vision this year? Get a sampling in the Best of Vision on Demand group.

AD Group membership not importing

Updated: 21 May 2010 | 6 comments
bmalt's picture
0 0 Votes
Login to vote
This issue has been solved. See solution.

I have Active Directory sync enabled in ServiceDesk.  It appears to import all my active directory users and all my active directory groups.  However, it does not appear to be importing Active Directory group membership, and it does not appear to be applying SD permissions that are attached to AD groups.

If I browse my AD groups via the ServiceDesk console, my AD groups show no members.  If I apply specific SD permission to an AD group, those permissions are not applied to the user accounts that are members of that group.  This could be related to the fact that SD is not showing group membership correctly, but it might be a separate issue.

I took a test AD group and applied rights equivalent to "KB editor" to the AD group within ServiceDesk.  I logged on as a member of that AD group and did not have KB edit rights.  Then I manually added the user to the AD test group within the ServiceDesk group manager.  After I made this manual change, the test group showed that one account, but that account still did not have KB edit rights.

Discussion Filed Under:

Comments

Rdutch12's picture
29
Sep
2009
0 Votes 0
Login to vote

it all comes down to how you

it all comes down to how you have set up your ad server in Service desk. By default all AD users are only added to the "All Users" group in SD.
So thats why your AD groups in SD dont show any members. Did you map any AD groups into SD groups during the install?
I personally don't import AD groups, just the users and them assign them manually one time to the correct SD groups.

Rob Hilberding Sr. Consultant ExpressAbility www.expressability.com

bmalt's picture
29
Sep
2009
0 Votes 0
Login to vote

Thanks for the reply.  No,

Thanks for the reply.  No, I did not map any AD groups to SD groups.  The way I read the instructions, that would mean the SD group name would not get created, only the AD group would get created.  I wanted to keep the SD groups intact so I could see what the default groups are.

So, you're saying, even though the "View Groups" in SD shows me all my AD groups, it doesn't really do anything with those groups?  I would prefer it not even display the AD groups if it's not going to use them for anything.  The fact that they are there leads to the assumption that you can actually assign SD permissions to AD groups.

Well, you can actually assign permissions to AD groups within SD but it doesn't work.

Jesper_Mathiasson's picture
29
Sep
2009
1 Vote +1
Login to vote

Hi ! You should be able to

Hi !

You should be able to set roles/permissions on AD-groups.

We have done many test-installations and tried AD-sync in different ways and are not finished yet. I believe there might be some issues but since it is not so well documented it's not that easy to know what kind of limitations there are. Fore example I cant get it to work with group in group and it doe sent sync correctly if user-names are too long.
Regarding group membership we have also seen some unexpected behavior but as stated before we will do more testing and  if we find errors we will log a case to Symantec.
If you didn't set up the AD account on the initial setup you are supposed to change them in Servicedesksetting on the Application Properties Profiles.

bmalt's picture
29
Sep
2009
0 Votes 0
Login to vote

So, Jesper, is ServiceDesk

So, Jesper, is ServiceDesk showing you users in your AD groups?  That's one of the things I can't get working.  I know the AD account is set up correctly because it's importing users and groups, it just appears that SD doesn't know which users are in which AD groups.

Also, are you able to apply SD permissions to you AD groups?  I mean, do they work once you apply them?  What I'm seeing right now is, no matter what permissions I assign to the AD groups, I have to put the user accounts into one of the built in groups before they can actually do anything in SD.

bmalt's picture
29
Sep
2009
0 Votes 0
Login to vote

Long user names is the issue

This is very interesting.  Based on what Jesper said about not syncing correctly if user names are too long, I created a test user with a short name.  I had two AD test groups I was testing membership with - both of these groups has 3 or 4 users in them, but neither of the groups have ever shown users from the SD console.

From AD, I added the short-name user to my TestGroup1, then did another AD sync.  After that AD sync SD was showing all the users in that group (including the previous long-named users that wouldn't sync up).

To make sure this was consistent, I created a second short-name user, added that user to my TestGroup2, and did another AD sync.  Sure enough, now TestGroup2 is showing all the members from the SD console.

That is the oddest bug.  So ServiceDesk isn't bombing out on long usernames per se, it is just requiring that at least one short-named user is in each group that you're trying to import.

The other issue still exists - I think I will start a separate post on that issue.  (the issue of applying SD permissions to AD groups has no effect.)

Chris Akeroyd's picture
16
Oct
2009
0 Votes 0
Login to vote

When I try to access the

When I try to access the ServiceDesk Setting under Application properties I get the following error. Any ideas?

Message: A column named 'ServiceDeskActiveDirectorySyncExchange' already belongs to this DataTable.
Log:
at System.Data.DataColumnCollection.RegisterColumnName(String name, DataColumn column, DataTable table) at System.Data.DataColumnCollection.BaseAdd(DataColumn column) at System.Data.DataColumnCollection.AddAt(Int32 index, DataColumn column) at System.Data.DataColumnCollection.Add(String columnName) at LogicBase.Ensemble.Profile.DisplayAndEditValues.Page_Init(Object sender, EventArgs e) at System.Web.Util.CalliHelper.EventArgFunctionCaller(IntPtr fp, Object o, Object t, EventArgs e) at System.Web.Util.CalliEventHandlerDelegateProxy.Callback(Object sender, EventArgs e) at System.Web.UI.Control.OnInit(EventArgs e) at System.Web.UI.Page.OnInit(EventArgs e) at System.Web.UI.Control.InitRecursive(Control namingContainer) at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)