LDAP authentication not pulling member of attribute
-
Hi!
We're on "2.3.2-RELEASE (amd64)", (open)LDAP is on Synology.
LDAP user test is member of grouptest
some-linux-machine# ldapsearch -x -LLL -H ldap://xxxx.xxxx.xxxx.xxxx -b uid=test,cn=users,dc=comp,dc=com memberOf
dn: uid=test,cn=users,dc=comp,dc=com
memberOf: cn=grouptest,cn=groups,dc=comp,dc=com
…so that looks good.
The "Authentication Servers" setup:query string: &(objectClass=person)(memberOf=cn=vpnusers,cn=groups,dc=comp,dc=com)
RFC 2307 Groups: tried both states
Group Object Class: posixGroupEverything works well for OpenVPN authentication, but the problem is I need to pull the LDAP memberOf attribute so I can assign pfSense permissions to the users (without having to create local user).
When I go to "Diagnostics / Authentication", I get:
User: test authenticated successfully. This user is a member of groups:
<empty>So my question is, why can't pfSense read the membeOf attribute (and linux-machine can)?TIA</empty>
-
I can't directly answer to your question but only provide some inputs and tracks for investigation.
1 - your basedDN is somewhat strange, IMHO
2 - I feel you mix-up some concepts and features about RFC2307memberof is an attribute managed at account's entry level to permit (is that a Microsoft invention with AD) to check which groups an account is member of without having to request groups ::)
Thus looking at this specific attribute doesn't really check group membership.Furthermore RFC2307, which, more or less, describes how to store in LDAP something like NIS maps, doesn't take this attribut in account. This doesn't matter in what we discuss here, but this is for your information ;)
In order to investigate further, I would suggest that you describe a bit more of your LDAP configuration, especially baseDN and filters.
Difference between RFC 2307 and 2307bis is, at this level, mainly the way group membership is checked. I don't know what is really done in pfSense but either description in GUI is misleading or if implementaiton follow what GUI states, then implementation is wrong, IMHO again.
-
Hi Chris!
1 - your basedDN is somewhat strange, IMHO
comp.dc is a dummy, I wanted to hide our realy company name. Or do you mean something else is strange?
In order to investigate further, I would suggest that you describe a bit more of your LDAP configuration, especially baseDN and filters.
I'm not sure where to find the information. In Synology there is not much to see:
FQDN: comp.com
Authentication: Base DN: dc=comp,dc=com
Authentication: Bind DN: uid=root,cn=users,dc=comp,dc=comSo the question would be: why does pfSense not see the groups the user is in?
-
What's kind of strange is not obviously the fact that you show fake dc but that your baseDN is the entry you target.
Obviously it works here but such settings only show that your entry contains attribute you want to retrieve and doesn't reflect what "standard" search filter would show.I agree it doesn't make real difference here… but it doesn't bring any added value too try using such baseDN.
And because of this, as I wrote, I wonder is problem is not due only to the fact that you are perhaps confused by "memberof" attribute as part of account's entry and "member" or "memberuid" (depending on RFC2307 implementation) showing real group members. -
Here is what I have for my OpenLDAP test setup here which works fine (needs RFC 2307 enabled):
-
Aside the initial question, I would like to react on this screen-copy and share my view with you.
RFC 2307 style group membership has members listed on the group object rather than using groups listed on user object. Leave unchecked for Active Directory style group membership (RFC 2307bis).
This is to me really confusing because purpose of RFC2307 is not this one, as far as I understand (and feel free to disagree on this and discuss further ;))
RFC 2307 has been written to describe how to store in LDAP equivalent of NIS maps, including therefore accounts and groups.
But group in LDAP, made of multivalued attribute (one value per member) can be handled either storing member's "uid" or member's DN
As a result, RFC2307 bis covers this difference (plus some other things related to objectclass structure)What does it mean (at least to me ;)):
- if you go for RFC2307, you expect to find in groups one attribute containing "uid" (matching accounts)
- if you go for RFC 2307 bis, you expect to find in groups one attribute containing "DN" (pointing to accounts)
and the fact that accounts entry contain or not "memberof" or 'ismemberof" attribute is not linked, to me, to this RFC2307.
In addition, to me, this way of dealing with "pseudo" group membership is misleading. I first discovered this very long time ago in AD (and more and more LDAP servers are maintaining plug-in ensuring that depending on how you populate your groups, equivalent (kind of) attribute is maintained at account's entry level.
For sure it help with only once single request to find account with filter based on group membership but is has a cost at LDAP server level and this is confusing ::)
IMHO only, obviously :P
-
Having struggled with this exact problem for a few days, I wanted to help others with the solution. Sorry for posting to a very old thread!
I am using the Synology Directory Server 2.2.1 on a Synology with DSM 6.1.5 installed, and PFSense 2.4.2.
The things I did to finally get it to work are:–-
On PFSense:System > User Manager > Authentication Servers > Add.
The important fields are:
Type: LDAP
Port: 389
Transport: TCP - Standard
Protocol version: 3
Search scope:- Level: Entire Subtree
- Base DN: (Base DN from Synology interface)
Authentication Containers: - (Bind DN from Synology interface, without 'cn=root,'). For example, mine is 'cn=users,dc=ldap,dc=example,dc=com'
Extended query: unchecked
Bind anonymous: checked (though I didn't test it with this checked, I just didn't want PFSense to have a valid LDAP password)
User naming attribute: cn
Group naming attribute: cn
Group member attribute: memberUid
RFC 2307 Groups: checked
Group Object Class: posixGroup
UTF8 Encode: checked (though, for me this didn't matter if it was checked or not)
Username alterations: unchecked (though I didn't test it with this checked)
Save
Next, In the Synology Directory Server interface go to:
Group > Create
Then create a group that the pfsense users will go in, mine is called 'pfsense_admins'
After the group is created, either click the Edit Members button and add the users you want, or go to the Users tab and add them to the pfsense_admins group.
If you plan to have different kinds of users access pfsense, make a group for each kind of user you'd like to authorize.
Next, back in PFSense:
System > User Manager > Groups > Add.
Create a group with the name 'pfsense_admins', this must be the same name as the group created in the Synology interface. I changed the scope to Remote, but it worked with either setting. Save that.Next, Edit that new group 'pfsense_admins' and give it the permissions desired. For this group, since it is targeted at administrators I gave it 'WebCfg - All pages' permissions.
If you plan to have different kinds of users access pfsense, make a group for each kind of user you'd like to authorize, and just be sure that the names in Synology are the same as the names in PFSense.
–-
To test, still in PFSense:
Diagnostics > Authentication.
Change Authentication Server to LDAP
Type in a valid LDAP username and password, it should return with "User x authenticated successfully. This user is a member of groups: pfsense_admins"
Lastly, enable LDAP to be used as the authentication source for PFSense.
System > User Manager > Settings. Change Authentication Server to 'LDAP', then Save & Test.All done! You should be able to log in with an LDAP user, and get the proper permissions assigned.
-
@zxjinn Thanks for that Informative Post. I was having trouble getting LDAP auth with pfsense and a Synology DiskStation to work but with your instructions it worked like a charm
-
@zxjinn Thank you, my setup started working after matching the group name from pfSense with the group name on Synology. That was the missing part for me!
