LDAP using AD and user group objects

[LightningMcQueen]

Hi all,

 

I am setting up a new LDAP connection to AD, based from our existing LDAP connections, in Martix v4.10.3.

The details screen is filled in, and says it is connected. I have set up the Attributes and User Setup also.

 

When I expand the LDAP bridge, it refreshes and loads no children/users (as though there are none in the AD group). As it is a new group we are setting up, to test it out we currently have 2 users in there.

 

The hostname and Bind DN are both fine; same as our other LDAP connections (which work).

 

There is a difference in AD with the groups though. From what the IT Techs have told me, our other LDAPs connect to display users stored in a folder, and the new one is a User Group Object.

 

I have obviously changed the Base DN, which starts with CN= (rather than our other LDAP bridges which start with OU=).

 

Would this impact the LDAP connection? Would I need to change any settings?

Could it be something in my Group Attributes?

 

Group Attributes are currently set the same as per our other connections;

Group Members: members

Group Name: dc

 

Help would be greatly appreciated! :) And probably needs to be in plain English, as I am not a programmer/tech; I know Matrix and it's assets, etc, (I'm a web person), but I have never even seen the interface for AD.

 

 

Thanks! Emily.

[gsherwood]

It is possible that the objectclass of the users or groups is not supported by Matrix yet. Matrix checks the objectclass of each item is gets back from an LDAP search to see if it should be a user, a group, or ignored (like workstations, printers and other custom objects).

 

Matrix supports groups that have an objectclass from this list:

organizationalunit

posixgroup

group

groupofnames

groupofuniquenames

domain

container

organization

country

 

Matrix supports users that have an objectclass from this list:

organizationalperson

inetorgperson

userproxy

 

So the first thing to check is if the missing items (directly under your base DN) have a different objectclass. If they do, there is a place in the Matrix code where you can add the objectclass to see if that is the cause.

 

If their objectclass attribute looks fine, then you just need to make sure that their DN sits under the base DN. SO if the base DN is ou=staff,dc=squiz,dc=net then those top-level users or groups must have a DN like uid=greg,ou=staff,dc=squiz,dc=net and not something like uid=greg,ou=currentstaff,dc=squiz,dc=net because the top level is located from a straight LDAP DN search and not a group member search. If your base DN is a group, it will often work to move the base DN one level up so you can see the group at the top level and not the users.

 

Hopefully that makes some sense.

 

 

[nnhubbard]

We use AD and have it correctly working in 4.14.2. Our users are in Groups. 

 

It took us weeks to finally get the setup working, so much trial and error. Not sure if our settings would be helpful:

 

[LightningMcQueen]

Hi Greg and Nic,

 

I have fwd this info to our AD techs, and they have send me an image which shows the Base DN group is of the ObjectClass "group"

and the users have the objectClass of Person; organizationalPerson; user

 

Both group and organizationalPerson are in the list, and I assume "user" as a subclass of organizationalPerson is also included?

 

 

Nic, I notice on your Base DN, yours starts with OU. our other ones start with OU, and this is one difference with our new one. The Base DN to use that the AD techs gave me was CN=BUS-L-SE-Intranet,OU=Security,OU=Staff,OU=BUS-Groups,OU=BUS,OU=MQ-BusUnit-Res,DC=mqauth,DC=uni,DC=mq,DC=edu,DC=au (note that it begins with CN).

Could this be causing the issue?

 

I have a very very very basic understanding of what OU (organisational unit?) and CN (common name?) are, but not enough to know how this affects connections.

 

(Note: changing CN to OU does not make it work. Wishful thinking though! ;) )\

 

 

Thanks!

Emily.

[gsherwood]

Yes, the objectclasses look good. Have you tried changing the base DN to: OU=Security,OU=Staff,OU=BUS-Groups,OU=BUS,OU=MQ-BusUnit-Res,DC=mqauth,DC=uni,DC=mq,DC=edu,DC=au

 

Assuming the user you are connecting as actually has access to that level. I'm just wondering if you see the BUS-L-SE-Intranet group on the top level when you set that base DN.

[nnhubbard]

Nic, I notice on your Base DN, yours starts with OU. our other ones start with OU, and this is one difference with our new one. The Base DN to use that the AD techs gave me was CN=BUS-L-SE-Intranet,OU=Security,OU=Staff,OU=BUS-Groups,OU=BUS,OU=MQ-BusUnit-Res,DC=mqauth,DC=uni,DC=mq,DC=edu,DC=au (note that it begins with CN).

 

I unfortunately don't know too much about it either. We worked with our IT Department to get it all setup, but it took much trial and error.

[Anthony]

I'm not an LDAP expert, but I have some experience (not with Squiz, just generally). As far as I know a Base DN can only be of the form OU-...OU=...DC=.

 

In LDAP terminology an OU is an "Organisational Unit", which is kind of like a folder in file share terms. A Base DN is a bit like saying "Which 'folder' fo you want to start searching from?" (Imagine you have a global directory with millions of objects in it, but you know for a particular requirement youre only concerned with users in the UK... you'd want to set your Base DN to the "UK" OU so it didnt waste time looking anywhere else.

 

A CN on the other hand is a specific "thing" - like a user or a group. Typically its the object(s) you find when you do the search. If a CN is a user, it has attributes like name, email address etc. For a group, one of the attributes will be all the members of the group.

 

In your case the CN=BUS-L-SE-Intranet suggests to me that is the name of the group, so what you really want is to retrieve that group, and then recognise all its members. Which is fine... if your system already knows about those users. I dont think it will work if the first thing it knows about the user is seeing them as group member. You need to be picking up all the users from within whatever their OU is. Once its done that to create the user accounts, I guess it can then make sense of their group membership.

 

I'm not sure if that makes things any clearer, but I hope it gives you a clue?

 

Good luck!

[LightningMcQueen]

Yes, the objectclasses look good. Have you tried changing the base DN to: OU=Security,OU=Staff,OU=BUS-Groups,OU=BUS,OU=MQ-BusUnit-Res,DC=mqauth,DC=uni,DC=mq,DC=edu,DC=au

 

Assuming the user you are connecting as actually has access to that level. I'm just wondering if you see the BUS-L-SE-Intranet group on the top level when you set that base DN.

 

I have tried to list it from the OU=Security level, and it still doesn't display any children.

 

I will double-check with IT about the read permissions, however I expect that would not be the issue as this group was created specifically for me to be able to access it.

 

 

A CN on the other hand is a specific "thing" - like a user or a group. Typically its the object(s) you find when you do the search. If a CN is a user, it has attributes like name, email address etc. For a group, one of the attributes will be all the members of the group.

 

In your case the CN=BUS-L-SE-Intranet suggests to me that is the name of the group, so what you really want is to retrieve that group, and then recognise all its members. Which is fine... if your system already knows about those users. I dont think it will work if the first thing it knows about the user is seeing them as group member. You need to be picking up all the users from within whatever their OU is. Once its done that to create the user accounts, I guess it can then make sense of their group membership.

 

We are using it as a group, correct. And trying to list all the members of the group.

 

The problem we are having is that our staff are listed in our AD on the basis of their payroll groups, which make up the OU groups. So, for my faculty we have most of the members in one OU, which is what we have had until now.

 

However, some of our staff are payed by the central body, and not our faculty, although they are physically housed within our building and do work 100% for our faculty. These staff are not within our OU, and thus the idea of a creation of the Membership Group. (Apparently one user cannot be in more than one OU). These staff are scattered throughout various other OU's.

 

I think I understand what you are saying in regards to it reading a membership group, but not actually reading the user account itself when it is in a CN group. As members of this group span many OU, does that mean I would need to tell it to read from basically all the OU groups, then filter it to say only read from users also mentioned in this CN membership group?

 

If so, how do I / can I do this?

 

 

Thanks again, 

Emily.

[Anthony]

Apparently one user cannot be in more than one OU

 

 

Correct - simplistically its  a bit like saying a file on your PC can't be in more than one folder. Your explanation certainly make it much clearer what your challenge is.

 

As members of this group span many OU, does that mean I would need to tell it to read from basically all the OU groups

 

 

I think that's exactly what you will need to do. If all the OU's your users are in come under one branch higher up the tree, then you could just specify that higher level OU and let the query ripple down through all the child OUs and find all your users.

 

As to exactly how you make Squiz "filter" the users you need, I'd have to defer to one of the Squiz guys here who have actually tried it. I'm afraid my knowledge of LDAP comes from another system and we dont integrate Squiz with AD in the way you are trying.

 

Good luck