[Freeipa-users] pfSense/FreeIPA LDAP Extended Query Fails

[Mike Jacobacci]

Hi,

I have just got authentication against my FreeIPA system working by following this:
https://ask.fedoraproject.org/en/que...uthentication/ <https://ask.fedoraproject.org/en/question/63089/how-can-i-integrate-freeipa-with-pfsense-for-authentication/>

The only change I had to make was to set the Search Scope level to "entire subtree" and I also left the extended query unchecked... With that setup I am able to authenticate using "Diagnostics->Authentication".

I really want to restrict access so I can use FreeIPA for our VPN auth so I tried using the following extended query but it fails:
&(memberOf=cn=admins,cn=groups,cn=accounts,dc=doma in,dc=com)

Looking in pfSense logs, using the extended query (fails):

[24/Aug/2016:11:07:16 -0700] conn=1396 fd=116 slot=116 SSL connection from * to *
[24/Aug/2016:11:07:16 -0700] conn=1396 TLS1.2 256-bit AES-GCM
[24/Aug/2016:11:07:16 -0700] conn=1396 op=0 BIND dn="" method=128 version=3
[24/Aug/2016:11:07:16 -0700] conn=1396 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[24/Aug/2016:11:07:16 -0700] conn=1396 op=1 SRCH base="cn=accounts,dc=domain,dc=com" scope=2 filter="(&(uid=user)(&(memberOf=cn=admins,cn=group s,cn=accounts,dc=domain,dc=com)))" attrs=ALL
[24/Aug/2016:11:07:16 -0700] conn=1396 op=1 RESULT err=0 tag=101 nentries=0 etime=0
[24/Aug/2016:11:07:16 -0700] conn=1396 op=2 UNBIND
[24/Aug/2016:11:07:16 -0700] conn=1396 op=2 fd=116 closed - U1

Without the query (success):
[30/Aug/2016:10:23:25 -0700] conn=6432 fd=110 slot=110 SSL connection from * to *
[30/Aug/2016:10:23:25 -0700] conn=6432 TLS1.2 256-bit AES-GCM
[30/Aug/2016:10:23:25 -0700] conn=6432 op=0 BIND dn="" method=128 version=3
[30/Aug/2016:10:23:25 -0700] conn=6432 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[30/Aug/2016:10:23:25 -0700] conn=6432 op=1 SRCH base="cn=compat,dc=domain,dc=com" scope=2 filter="(uid=user1)” attrs=ALL
[30/Aug/2016:10:23:25 -0700] conn=6432 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[30/Aug/2016:10:23:25 -0700] conn=6432 op=2 BIND dn="uid=user1,cn=users,cn=compat,dc=domain,dc=com " method=128 version=3
[30/Aug/2016:10:23:25 -0700] conn=6432 op=2 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=user1,cn=users,cn=accounts,dc=domain,dc=co m"
[30/Aug/2016:10:23:25 -0700] conn=6433 fd=118 slot=118 SSL connection from * to *
[30/Aug/2016:10:23:25 -0700] conn=6432 op=3 UNBIND
[30/Aug/2016:10:23:25 -0700] conn=6432 op=3 fd=110 closed - U1
[30/Aug/2016:10:23:25 -0700] conn=6433 TLS1.2 256-bit AES-GCM
[30/Aug/2016:10:23:25 -0700] conn=6433 op=0 BIND dn="" method=128 version=3
[30/Aug/2016:10:23:25 -0700] conn=6433 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn=""
[30/Aug/2016:10:23:25 -0700] conn=6433 op=1 SRCH base="uid=user1,cn=users,cn=compat,dc=domain,dc=co m" scope=2 filter="(uid=user1)” attrs="memberOf"
[30/Aug/2016:10:23:25 -0700] conn=6433 op=1 RESULT err=0 tag=101 nentries=1 etime=0
[30/Aug/2016:10:23:25 -0700] conn=6433 op=2 UNBIND
[30/Aug/2016:10:23:25 -0700] conn=6433 op=2 fd=118 closed - U1

I changed the cn from accounts to compat for the auth container, but that doesn't make a difference. The last search shows attrs="memberOf", but anytime I add an extended query the logs show attrs="all", not sure if that means anything. I tried adding the full memberOf path under the group member attribute, but that didn't restrict access although the auth is still success.

[30/Aug/2016:10:42:12 -0700] conn=6460 op=1 SRCH base="uid=user3,cn=users,cn=compat,dc=domain,dc=co m" scope=2 filter="(uid=user3)" attrs="memberof=cn=admins,cn=groups,cn=compat,dc=d omain,dc=com"
[30/Aug/2016:10:42:12 -0700] conn=6460 op=1 RESULT err=0 tag=101 nentries=1 etime=0

When doing an ldapsearch, I can see the group:

# admins, groups, compat, domain.com
dn: cn=admins,cn=groups,cn=compat,dc=domain,dc=com
ipaAnchorUUID:: 
gidNumber: 50000
memberUid: admin
memberUid: user1
memberUid: user2
objectClass: posixGroup
objectClass: ipaOverrideTarget
objectClass: ipaexternalgroup
objectClass: top
cn: admins

Any help would be greatly appreciated.

Cheers,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160831/c13c775b/attachment.htm>