Can't Authenticate Against Joined Data Source

[tjclayton]

We have configured a join between two LDAP data sources. I can authenticate users against the primary, but I cannot authenticate the user with the password associated with the joined source. If I authenticate directory against the proxy for the joined source it works. I have tried not setting bindPrimaryFirst, leaving it blank, setting it to true and setting it to false. None of the the variations seem to make a difference.

I have attached a debug log and the conf file. I'm not sure that I even see an attempted bind against the joined source.

Any ideas are appreciated. Thanks.
myvd.conf.txt
myvd.log.zip

[mlbiam]

When debugging joins, the first thing I generally do is add a DumpTransactions insert to each namespace to see what operations are being performed on each namespace, what mappings are happening, etc. I see that you're mapping between title and uid. I've found that having different attribute names can cause issues because we attempt to figure out which base to search first. You want to have the attribute names lineup in the joinFilter. You can do this by adding a net.sourceforge.myvd.inserts.mapping.AttributeMapper in the front of the BaseServer2 namespace. Best practices for joiners:

1. Define your source data in non-overlapping namespaces - I usually define my joined namespaces in a root like ou=Data so there are no potential routing conflicts
2. The first insert in the global chain should be the AttributeCleaner insert with clearAttributes set to true
3. While debugging, add a DumpTransactions insert in front of the chains for each namespace to see how the LDAP searches are proceeding

That said, what are you attempting to do? It looks like you have one directory for groups and another for users?

[tjclayton]

Everything with the join works fine. The issue is with authentication. It looks like the bindPrimaryFirst config should control this, but no matter what it is set to (or not set) authentication is not working against the joined namespace. Authenticating against the joined namespace directly through the proxy works fine. There are two matching users and when I added the clearAttributes as suggested in the other issues, the attributes come back fine. It is a quick test to check the attributes and authentication. It isn't an actual set of data.

Sorry, I was under the impression that putting the DumpTransactions in the global chain it would apply to everything, but it doesn't look to work that way, I guess.

[mlbiam]

Sorry, I was under the impression that putting the DumpTransactions in the global chain it would apply to everything, but it doesn't look to work that way, I guess.

No, the joiner doesn't go back through the global chain so you need to add DumpTransactions to each chain

[tjclayton]

I have added a DumpTransactions to the joiner and there is still no obvious information as to why authentication against the joined target is not working.

[2020-09-01 09:01:04,245][pool-4-thread-1] INFO  DumpTransaction - [Global] Begin Bind : uid=afuller,ou=people,o=joinedldap,c=US
[2020-09-01 09:01:04,246][pool-4-thread-1] INFO  DumpTransaction - [JOIN] Begin Bind : uid=afuller,ou=people,o=joinedldap,c=US
[2020-09-01 09:01:04,247][pool-4-thread-1] INFO  DumpTransaction - [JOIN] Begin Seach - Filter=(objectClass=*);Base=uid=afuller,ou=people,o=joinedldap,c=US;Scope=0;Attributes=joinedDNs joinedBases 
[2020-09-01 09:01:04,264][pool-4-thread-1] INFO  DumpTransaction - [JOIN] Seach submitted
[2020-09-01 09:01:04,264][pool-4-thread-1] INFO  DumpTransaction - [JOIN] Begin Post Search Entry - Filter=(objectClass=*);Base=uid=afuller,ou=people,o=mycompany,c=us;Scope=0;Attributes=[LDAPAttribute: {type='joinedDNs'}, LDAPAttribute: {type='joinedBases'}]
dn : uid=afuller,ou=people,o=mycompany,c=us
uid : afuller
objectClass : inetOrgPerson
objectClass : organizationalPerson
objectClass : person
objectClass : top
myVdReturnEntry: true
[2020-09-01 09:01:04,265][pool-4-thread-1] INFO  DumpTransaction - [JOIN] Post Seach Entry Complete
dn : uid=afuller,ou=people,o=joinedldap,c=US
uid : afuller
objectClass : inetOrgPerson
objectClass : organizationalPerson
objectClass : person
objectClass : top
myVdReturnEntry: true
[2020-09-01 09:01:04,288][pool-4-thread-1] INFO  DumpTransaction - [JOIN] Error Running Bind
com.novell.ldap.LDAPException: Invalid Credentials
	at net.sourceforge.myvd.inserts.join.Joiner.bind(Joiner.java:245) ~[myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:49) ~[myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.inserts.DumpTransaction.bind(DumpTransaction.java:143) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:49) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.router.Router.bind(Router.java:151) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:52) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.inserts.mapping.AttributeCleaner.bind(AttributeCleaner.java:96) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:49) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.inserts.DumpTransaction.bind(DumpTransaction.java:143) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:49) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.server.apacheds.MyVDInterceptor.bind(MyVDInterceptor.java:265) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.core.DefaultOperationManager.bind(DefaultOperationManager.java:439) [myvd-server-1.0.9.jar:2.0.0-M20]
	at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handleSimpleAuth(BindRequestHandler.java:177) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:557) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:61) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:193) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:217) [apacheds-service-2.0.0-M20.jar:?]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:854) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:475) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:429) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
[2020-09-01 09:01:04,303][pool-4-thread-1] INFO  DumpTransaction - [JOIN] Bind Complete
[2020-09-01 09:01:04,304][pool-4-thread-1] INFO  DumpTransaction - [Global] Error Running Bind
com.novell.ldap.LDAPException: Invalid Credentials
	at net.sourceforge.myvd.router.Router.bind(Router.java:161) ~[myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:52) ~[myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.inserts.mapping.AttributeCleaner.bind(AttributeCleaner.java:96) ~[myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:49) ~[myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.inserts.DumpTransaction.bind(DumpTransaction.java:143) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.chain.BindInterceptorChain.nextBind(BindInterceptorChain.java:49) [myvd-server-1.0.9.jar:?]
	at net.sourceforge.myvd.server.apacheds.MyVDInterceptor.bind(MyVDInterceptor.java:265) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.core.DefaultOperationManager.bind(DefaultOperationManager.java:439) [myvd-server-1.0.9.jar:2.0.0-M20]
	at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handleSimpleAuth(BindRequestHandler.java:177) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:557) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.ldap.handlers.request.BindRequestHandler.handle(BindRequestHandler.java:61) [myvd-server-1.0.9.jar:?]
	at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:193) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.directory.server.ldap.handlers.LdapRequestHandler.handleMessage(LdapRequestHandler.java:56) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.handler.demux.DemuxingIoHandler.messageReceived(DemuxingIoHandler.java:221) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.directory.server.ldap.LdapProtocolHandler.messageReceived(LdapProtocolHandler.java:217) [apacheds-service-2.0.0-M20.jar:?]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$TailFilter.messageReceived(DefaultIoFilterChain.java:854) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.filterchain.IoFilterEvent.fire(IoFilterEvent.java:74) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.core.session.IoEvent.run(IoEvent.java:63) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.runTask(UnorderedThreadPoolExecutor.java:475) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at org.apache.mina.filter.executor.UnorderedThreadPoolExecutor$Worker.run(UnorderedThreadPoolExecutor.java:429) [apacheds-service-2.0.0-M20.jar:2.0.0-M20]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_265]
[2020-09-01 09:01:04,305][pool-4-thread-1] INFO  DumpTransaction - [Global] Bind Complete

Any ideas?

[mlbiam]

is the password on the primary or the joined entries?

[tjclayton]

Both. I can authenticate with the password on the primary account, but I can't authenticate with the password on the joined account. I have tried not setting bindPrimaryFirst, leaving it blank, setting it to true and setting it to false. None of the the variations seem to make a difference.

We did test this with version 0.9x (I believe since I didn't actually perform the test) with the same configuration and it worked when set to false. I can't see to get this working in 1.0.9, though. Thanks.

[mlbiam]

OK, so i want to make sure i understand, is this accurate?

bindPrimary	Password on Primary	Password on Joined	Works
true	true	false	true
true	false	true	false
false	true	false	true
false	false	true	false

[tjclayton]

That looks like the behavior I am seeing. Thanks.

[mlbiam]

ok, so i think whats happening is that when the search happens to look for the joined entries, MyVD finds the user in o=mycompany,c=us (BaseServer) but not the user in BaseServer2. The results don't have the joinedDNs or joinedBases attributes. Try adding the AttributeCleaner insert on both BaseServer and BaseServer2 as the first insert, with clearAttributes set to true. Looking at the code i'm wondering if by trying to limit what attributes I get back I'm breaking the join process.

[tjclayton]

OK. I will give that a shot. We do have AttributeCleaner specified in the global chain (which allowed the joined attributes to come back), but I will try adding it at that level as well.

The results are joined correctly and the joined attributes are there. I think I did not export the operational attributes before which caused the confusion. Sorry.

dn: uid=afuller,ou=people,o=joinedldap,c=US
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Ann Fuller
sn: Fuller
info: sthompson
initials: AOR
l: Rhinelander
mobile: +1 164 286 4924
pager: +1 604 109 3407
title: user.0
uid: afuller
userPassword:: e1NTSEF9bGM2NWFINVhwdmRGTitpNWJZdG9JZEZ1aVF3UUcvWDlyTVgvZGc9P
 Q==
userPassword:: e1NTSEF9b0ZBa21Ld0YzQlV5QXlJc2J3YXR6KzNvdTJqRVI4RzBlQ3BzcEE9P
 Q==
createTimestamp: 20200819134827.636Z
creatorsName: cn=Directory Manager
entrydn: uid=afuller,ou=people,o=mycompany,c=us
joinedBases: dc=coreblox,dc=com
joinedDNs: uid=user.0,ou=People,dc=coreblox,dc=com
modifiersName: cn=Directory Manager
modifyTimestamp: 20200901125458.045Z
primaryBase: o=mycompany,c=us
primaryDN: uid=afuller,ou=people,o=mycompany,c=us
pwdChangedTime: 20200901125458.045Z

I appreciate it.

[tjclayton]

I added the AttributeCleaner to BaseServer and BaseServer2 and I am still seeing the same behavior. Please let me know if you want me to try anything else. I also tried adding it directly to the join. Thanks.

[mlbiam]

I'm wondering if this is a bug. i'll add a test case and see if i can reproduce

[tjclayton]

Thanks. I appreciate it.