LDAP bridge ldproxy not returning memberOf attribute

[Colin]

Hello, I've been executing some testing with the LDAP bridge (ldproxy) and was having some problems getting some of our devices to authenticate properly.

It turns out some of our devices require information about the memberOf attribute when querying a user DN.

However, it looks like the RCdevs LDAP bridge strips out memberOf information from certain queries.

Here is a example query using ldapsearch to a Windows 2012 R2 server (all info is test so passwords/DNs are not production):

======

ldapsearch -h 10.203.37.211 -p 389 -D "cn=ldapbind,ou=Users,ou=Operations,dc=central,dc=home" -w Asdf123\$ -b "cn=supervisor,ou=Users,ou=Operations,dc=central,dc=home" "objectclass=*"

# extended LDIF

#

# LDAPv3

# base <cn=supervisor,ou=Users,ou=Operations,dc=central,dc=home> with scope subtree

# filter: objectclass=*

# requesting: ALL

#

# supervisor, Users, Operations, central.home

dn: CN=supervisor,OU=Users,OU=Operations,DC=central,DC=home

objectClass: top

objectClass: webadmAccount

objectClass: person

objectClass: organizationalPerson

objectClass: user

cn: supervisor

givenName: supervisor

distinguishedName: CN=supervisor,OU=Users,OU=Operations,DC=central,DC=home

instanceType: 4

whenCreated: 20161006213211.0Z

whenChanged: 20161007172352.0Z

displayName: supervisor

uSNCreated: 16464

memberOf: CN=Supervisors,OU=Groups,OU=Operations,DC=central,DC=home

uSNChanged: 28714

name: supervisor

objectGUID:: bvYg3ZMgwEGayyL7Ar9rdA==

userAccountControl: 66048

badPwdCount: 0

codePage: 0

countryCode: 0

badPasswordTime: 0

lastLogoff: 0

lastLogon: 0

pwdLastSet: 131202631319603949

primaryGroupID: 513

objectSid:: AQUAAAAAAAUVAAAAHP27ZyvH9FeW/VgsRgYAAA==

accountExpires: 9223372036854775807

logonCount: 0

sAMAccountName: supervisor

sAMAccountType: 805306368

userPrincipalName: super...@central.home

objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=central,DC=home

dSCorePropagationData: 16010101000000.0Z

lastLogonTimestamp: 131202663934923130

webadmData: OpenOTP.LastLogin=MjAxNi0xMC0wNyAxMDoyMzo1Mg==,OpenOTP.LoginCount=

 MjM=,DataMode=A4H1CQk=

# search result

search: 2

result: 0 Success

# numResponses: 2

# numEntries: 1

======

Here is an example querying ldproxy with the Windows 2012 R2 server as the backend:

======

ldapsearch -h 10.203.37.140 -p 10389 -D "cn=ldapbind,ou=Users,ou=Operations,dc=central,dc=home" -w Asdf123\$ -b "cn=supervisor,ou=Users,ou=Operations,dc=central,dc=home" "objectclass=*"

# extended LDIF

#

# LDAPv3

# base <cn=supervisor,ou=Users,ou=Operations,dc=central,dc=home> with scope subtree

# filter: objectclass=*

# requesting: ALL

#

# supervisor, Users, Operations, central.home

dn: cn=supervisor,ou=Users,ou=Operations,dc=central,dc=home

objectClass: top

objectClass: WEBADMACCOUNT

objectClass: person

objectClass: organizationalPerson

objectClass: USER

cn: supervisor

givenName: supervisor

distinguishedName: cn=supervisor,ou=Users,ou=Operations,dc=central,dc=home

INSTANCETYPE: 4

WHENCREATED: 20161006213211.0Z

WHENCHANGED: 20161007172352.0Z

DISPLAYNAME: supervisor

USNCREATED: 16464

USNCHANGED: 28714

name: supervisor

OBJECTGUID:: bvYg3ZMgwEGayyL7Ar9rdA==

USERACCOUNTCONTROL: 66048

BADPWDCOUNT: 0

CODEPAGE: 0

COUNTRYCODE: 0

BADPASSWORDTIME: 0

LASTLOGOFF: 0

LASTLOGON: 0

PWDLASTSET: 131202631319603949

PRIMARYGROUPID: 513

OBJECTSID:: AQUAAAAAAAUVAAAAHP27ZyvH9FeW/VgsRgYAAA==

ACCOUNTEXPIRES: 9223372036854775807

LOGONCOUNT: 0

sAMAccountName: supervisor

SAMACCOUNTTYPE: 805306368

userPrincipalName: super...@central.home

OBJECTCATEGORY: CN=Person,CN=Schema,CN=Configuration,DC=central,DC=home

DSCOREPROPAGATIONDATA: 16010101000000.0Z

LASTLOGONTIMESTAMP: 131202663934923130

WEBADMDATA: OpenOTP.LastLogin=MjAxNi0xMC0wNyAxMDoyMzo1Mg==,OpenOTP.LoginCount=

 MjM=,DataMode=A4H1CQk=

# search result

search: 2

result: 0 Success

# numResponses: 2

# numEntries: 1

======

Note that memberOf is not returned by ldproxy.

Is this by design? I've narrowed this down as the problem some of our devices are having with not being able to authenticate through ldproxy.

Note that watching the backend server, it does return the memberOf attribute when returning information to the ldproxy, so the LDAP bridge must be stripping the information somewhere.

[Colin]

Bump

[Spyridon Gouliarmis (RCDevs)]

Anyone able to help here is still to busy. Running ldproxy in debug mode might give a hint as to what goes wrong, if you want to troubleshoot this yourself. (service ldproxy debug, after shutting it down)

The time-consuming part is finding the relevant lines in the verbose output. It's an OpenLDAP slightly modified with a plugin, if you need doc to interpret it.

On Tuesday, October 11, 2016 at 6:59:25 PM UTC+2, Colin wrote:

Bump

[Colin]

No worries. Here is my noob analysis.

I am attaching two logfiles, LOG1.txt and LOG2.txt

In LOG1.txt, the user "supervisor" is a memberOf the "Supervisors" group.

In LOG2.txt, the user "supervisor" is a memberOf the "Engineers" group.

In the original attribute return from the active directory server to OpenOTP, the memberOf attribute is between the USNCREATED and USNCHANGED attributes, as you can see above. USNCREATED attribute is proxied at line 2830 in LOG1.txt. At line 3032, a "dnPretty" function "normalized" the DN string of the memberOf group, but does not seem to get proxied successfully. At line 3106, USNCHANGED is proxied successfully.

From my untrained eye, it seems like the "dnPretty" function is doing something to prevent the memberOf attribute from being returned properly. The only other times dnPretty comes into play is when it is catching user DNs.

[francois...@rcdevs.com]

Hello 

It seems that memberof is a special attribute which is calculated, so you need to request it explicitly.

Could you try  this :

ldapsearch -h 10.203.37.211 -p 389 -D "cn=ldapbind,ou=Users,ou=Operations,dc=central,dc=home" -w Asdf123\$ -b "cn=supervisor,ou=Users,ou=Operations,dc=central,dc=home" memberof

[Colin]

That did work, thanks for the tip.

Unfortunately the devices I mentioned above as not working hardcode the LDAP search function and I have no ability to change it.

Would there be any "easy" way to allow ldproxy to return memberOf without the specific memberof attribute search?

[Αγησίλαος Παπαδόκωστας]

Any update on this one? I am also looking for the missing memberOf attribute. I can also clearly see that it is returned from the active directory server to openotp, and lost somewhere between openotp and ldproxy.

[Colin]

nothing yet