Directory Programming .NET

Hi,

I have posted before about synching AD with mysql using DirSync. It works all fine for simple groups but for nested groups it fails.  I retrieve all the groups starting with a perticular name and searches for their members but of course if the members are sub groups it would not work.

I read post on token groups but the search is performed on user level.

I need to perform search on group level and retrieve the users in the group. Is there a way to check if the retrieved member is a group or user?

---

kk

What about DirSync fails when using nested groups?

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

The way I am doing right now is get the group, retrieve the member's DN and then again bing to AD to perform attribute scope search using the DN to get all of the samAccoutnName.  But if its is a sub group the attribute level search fails sinc its done on a user.

One way I can think if is to check for the member atrtribute if that is not null then it is a group but it will be null aswell if there are no users in the group.

So was windering if there is another effective way to check if the member of a group is subgroup or a user.

---

kk

Rather than bind to the objects themselves, just do a search and append a clause to the filter like (objectClass=group), for example (&(objectClass=group)(samAccountName=someName)) and do a search for that object.  If it returns nothing then it wasn't a group.

Thats a good idea. But i have managed it by doing an attribute search on the member of a grop, retrive the object catagory and checking if the it begins with 'cn=group'. hoping I am doing right.

But the problem is much deeper for the update search. I am using a search filter '(&(objectCategory=group)(sAMAccountName=test*))', to search for the group starting with test(eg test1, test2). But if the sub group inside the 'test1' group is not named starting with 'test' then i dont get any update. Which is ofcourse due to the search filter I am specifying.

Any idea how to get around it.Can I get updates on any changes done to the sub groups as well?

Thanks in advance.

---

kk

I am still unclear what the issue here is.  What about DirSync fails?  You seem to be talking about ASQ here.  Are you getting an error, or are you just not getting results you expect?

I guess it would be more important for me to understand your scenario and then I can tell you how to apply DirSync and/or ASQ to get the desired effect.

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

My apologies should have been more clear. My code uses DirSync to get the updates from Active Directory.

1 There are two scenarios one is a full synchronization(Which gets all the group starting with the string test) and then the  update synchronization (i.e. any changes that occur in the obtained groups). 

 2 My search filter is as follows (&(objectClass=group)(sAMAccountName=test*)).

 3 During synchronization I get the DN of members in the groups and bind using ASQ to AD again with a new connection to get the sAMAccountName of each member.

4 My problem before  was if the member was a sub group and not a user then my ASQ would fail due to my search filter which only searches for users. But now I got around it by specifying in the ASQ search filter to search for groups and users

5 So the problem is solved for full synchronization process. The groups starting with 'test'  and their users and sub groups are successfully processed.

6 Now the problem arrives during update synchronization. Since the search filter in step 2 gets only the updates for groups starting with 'test' (eg test1,test2,test3), if the  group has nested group which does not start with 'test' (e.g. test1 group has a sub group name subgroup1) then the updates happening in sub group (subgroup1) are not received.

So if a user is added or deleted from the sub group I do not get any notification from Active Directory.  I would like to know if there is a way of specifying the search filter so that I can get the updates in top level groups (test1) and the sub group (subgroup1). 

---

kk

I think I understand now.  Let me reiterate what I think you are saying:  you have a group, called 'test1' for instance that has a nested membership of another group called 'foo'.  Changes are happening inside of 'foo' and indirectly changing the membership of 'test1', and you do not see the updates coming across on DirSync.  That is expected based on your initial filter.

The solution of course is to open your filter up more.  Provide the initial filter as all groups.  Next, filter only for changes for 'Test' groups and do not update the cookie yet.  For each 'Test' group, do a recursive search for each nested group and maintain a hashtable then.  Finally, use the same DirSync query again (the one you didn't update the cookie on - just change the filter now) and look for all the groups inside your hashtable.  This will tell you which nested groups were updated.

Definitely more complicated.  Of course, if you just designed the solution to work with all groups (not just test groups) and then later filtered out the ones you weren't interested in, it might be less complex.

---

Ryan Dunn
Extemporaneous Mumblings
The .NET Developer's Guide to Directory Services Programming

Neat Idea but I am only interested in 10 groups in some 100 groups scale. It would be a huge weight on the network but doesnt seem to be any other better solution unless I dynamically update the search filter adding the subgroups in it.


I think DirSync has a long long way to go. I found the changes donot come through even when the complete subgroup is removed from parent distribution group.  That is a direct change in membership still nothing. It certainly needs a lot of improvement.

---

kk

Well another interesting observation. The nested group problem does not occur if the parent is a "Domain Local Distribution Group" but if the parent is "Global Distribution Group" it does not work.  Wonder what would be the difference be.

---

kk