FOG 1.5.10.1604 ldap plugin

[AUTH IT Center]

@Tom-Elliott though I deployed it on our production server (from my fork), of course when you push the changes I can test it on the staging server. Just let us know.

[Tom Elliott]

@AUTH-IT-Center I’m asking about testing working-1.6 lol selfishly. Keep using what you’ve done though I did find I think 1 issue in your code (a place where admingroups should be usergroups)

[AUTH IT Center]

@Tom-Elliott Ι did try the 1.6 branch but didn’t work… that’s when I started debugging on 1.5.10.1064 dev-branch. I made the changes based on our LDAP needs. It would be proper if all the parameters came from the LDAPServers table and dynamically used in the code (even the filter maybe?)

[Tom Elliott]

@AUTH-IT-Center After some pretty serious testing I think I finally got the ldap plugin working on 1.6 as well.

I can make the suggested changes in dev-branch, but that might remove your PR. I can merge yours in, then refactor it so at least you get the due credit, I just refined it to make it more robust?

Hopefully that will help.

your uid=… method it’s not perfect.

Your filter should be:

<groupNameAttribute=<group1>, etc…<groupMemberAttribute=<userdn/or uid information>

So group name I think was always expected to be name for some period of time, though has been refactored to allow

The purpose of the groupMemAttr is the member attribute, not the group name attribute (which I think is what you’re using it for currently?)

The idea of this is:

check all groups (with name as the key indicator explicitely defined unfortunately in dev-branch) that match the name of . whatever group search you’re doing (admin or user) (This is psuedo code of representation for the filter logic ideals:

if (name = this OR name = that OR name = other) {
    AND (if <userDN> is in the member list of this group) {
        This is the access level
    }
}

Your method is saying:

if (member = this OR member = that) { // Here you're using member but using the group name attribute to select it?
    AND (if usernameattribute == username) { // this would be true if the bind already read worked.
    }
}

Basically the problem with your current filter is you only check if the group exists and the username = username, not that the username actually is a member of that group.

We do have logic, I think that double checks but I hope you can see the issue here?

[AUTH IT Center]

@Tom-Elliott said in FOG 1.5.10.1604 ldap plugin:

@AUTH-IT-Center After some pretty serious testing I think I finally got the ldap plugin working on 1.6 as well.

Basically the problem with your current filter is you only check if the group exists and the username = username, not that the username actually is a member of that group.

We do have logic, I think that double checks but I hope you can see the issue here?

Hello @Tom-Elliott and thank you in advance for your time and effort. The changes that we tried to implement came from this post.

To better give you the concept we are trying to achieve let me explain with our setup and attributes.

What we want is that if a user trying to login to FOG server with his uid = username and is member with specific eduPersonEntitlement(s) can login to FOG server and be member of the FOG admins.

[Tom Elliott]

@AUTH-IT-Center In my testing with an openldap (ldap.forumsys.com)
https://www.forumsys.com/2022/05/10/online-ldap-test-server/

I wasn’t able to use member/memberof though I wasn’t able to figure out quite why, but when I changed the group member to ‘uniquemember’ all seemed to work.

Assuming eduPersonEntitlement has the uids (in dn format) of the user (either full dn or partial) and it’s directly associated with the ou structure for your admin group:

Similarly your ‘admingroup’ (I know you’ve masked it) but do you have a group in your LDAP that has a full name of: https://entitlements.it.auth.gr/<adminGroupName>?

Now I’m not sure on the exact setup differences (I just helped get the plugin built)

In my experience:
Search base DN tells us where it’s going to search for users
Group base DN tells us where it’s going to search for groups

So if Groups are all under the OU=People,O=Auth,C=GR then this would work, but if groups are not all under OU?

In my example structure my layout was:

LDAP Server -> ldap.forumsys.com
LDAP Server Port -> 389
Use Group Matching (recommended) checked
Search Base DN -> dc=example,dc=com
Group Search DN -> dc=example,dc=com
Administrator Group -> mathematicians
Non-Administrator Group ->
Username Attribute -> uid
Group Name Attribute -> ou #Working-1.6 has this element
Group Member Attribute -> uniquemember
Search Scope -> Subtree and Below
Bind DN -> cn=read-only-admin,dc=example,dc=com
Bind Password -> password

Of course I don’t expect anyone to actually use this setup and this is for testing, not for real login, but gave me a way to test things.

Search Base DN = Where we search for users
Group Search DN = Where we search for groups
Admin/user Group = What groups should users belong in (must reside in the Group Search DN to work.)
Username Attribute = We all know this one
Group Name Attribute = This is new to working-1.6 of course but similar to username attribute. In your case this would be defaulted to name in dev-branch
Group Member Attribute = which attribute stores users that are associated to the group.
Search Scope = Base = Only at the search base, Subtree = Only at the group below the search base, Subtree and below = Everthing from the group base and below. (this is just how I imagine and envision it, if anyone has better descriptions feel free to correct me please.)

Bind DN (what user dn is to authenticate intially with the ldap)
Bind Password (what password to authenticate with)

I know I was explicit but this is what worked for me in my testing.

[AUTH IT Center]

@Tom-Elliott being explicit helped me better understand the verification process.

Similarly your ‘admingroup’ (I know you’ve masked it) but do you have a group in your LDAP that has a full name of: https://entitlements.it.auth.gr/<adminGroupName>?

yes it’s a full html path

I used the filter from the original code and the results are:

Admin search
Filter: (&(|(name=https://entitlements.it.auth.gr/<adminGroupName>))(edupersonentitlement=uid=usename,ou=People,o=auth,c=gr)); Result: 0

Mobile Search (empty group)
Filter: (&(|(name=))(edupersonentitlement=uid=username,ou=People,o=auth,c=gr)); Result: 0

The correct filter should be (that is what I implemented):

Admin search
Filter: (&(|(edupersonentitlement=https://entitlements.it.auth.gr/<adminGroupName>))(uid=username))

Mobile search
Filter: (&(|(edupersonentitlement=https://entitlements.it.auth.gr/<userGroupName>))(uid=username))

[Tom Elliott]

@AUTH-IT-Center I think, at least with what limitations I have this would work just fine in working-1.6

Except you’d be setting the groupNameAttr = edupersonentitlement

My filter query is built as such:

(&(|(%s=%s))(|(%s=%s)(%s=%s=%s)(%s=%s)))

basically it builds it out as:
<group name attribute>=<groups to associate> (and broken into multiple if and as necessary)
<group member attribute>=<userDN>
<group member attribute>=<user name attribute>=<username>
<user name attribute>=<username>

This is built as an AND or (and) or

So in psuedo code:

if (groupNameAttr = <value> or .... or ... or)

AND 

if (groupMember = <userDN> or groupMember = userName = <user> or userName = <user>)

then it should work.
I don’t have a way to represent it, Just saying I think we are covering those basis in working-1.6 (among many other potentials).

[AUTH IT Center]

@Tom-Elliott I will test your new code from working-1.6 branch on our dev server and report back (tomorrow).

[Tom Elliott]

@AUTH-IT-Center Roger and it is much appreciated

[AUTH IT Center]

@Tom-Elliott couldn’t wait till tomorrow… tested with 1.6 and works with the below settings.

also in 1.6 you need to change Subree on line 988 also.

Thank you once more for your time and effort.

[Tom Elliott]

@AUTH-IT-Center Subree is updated to be properly listed as Subtree