Shib / ldap search base

[Dave Vernon]

Hello again,

As you know, yesterday was an exciting day for me, getting my first Shibboleth project running in my dev environment. My users are held in a Microsoft Active Directory (2008 R2 DC's, 2003 functional level). I was aware that the default search base is CN=Users so I had put my test user there.

Today I went to expand that and I've run into issues. I'd like to be able to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca , so I edited my attribute-resolver.xml file on my IdP, restarted the service, and tested. I found that it wasn't working - users NOT in the cn=users container were rejected by Shib, and my test user in the cn=users container was authenticated by Shib but rejected by the resource I'm protecting (remote_user not set)

I checked the documentation I see the common cause seems to revolve around refers. The docs say that I need to set <LDAPProperty name="java.naming.referral" value="follow"/> , as it is 'ignore' by default. I think that's actually old information because I can verify that in my instance it was set to 'follow' by default.

The other fix is to search a GC instead - which is not a problem for me ("horus" is a GC). I changed my ldapURL to use port 3268 (plain old) but I'm still getting the same results. If I move a user into the cn=users container they work, but if they aren't there, they won't authenticate.

Here is my attribute-resolver.xml

<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
useStartTLS="false"
ldapURL="ldap://horus.ADS.LOYALISTCOLLEGE.CA:3268" baseDN="DC=ads,DC=loyalistcollege,DC=ca" principal="ldapqsvc-***@public.gmane.orgege.ca"
principalCredential="password removed for post">
<FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</FilterTemplate>

<!-- We rely on the uniqueness of the objectSid. But it is binary so we *must* make it so -->
<LDAPProperty name="java.naming.ldap.attributes.binary" value="objectSid"/>
<!-- If we are following from the GC we need thus on -->
<LDAPProperty name="java.naming.referral" value="follow"/>

</resolver:DataConnector>




And a snip from my idp-process.log

javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn



Any thoughts? I also read that I could stack multiple searches, which would also work for me ( I only have 3 or 4 OUs where users are) so I tried changing the base path to a specific OU where a user is, but I was also unable to authenticate.


Dave Vernon
Technology Infrastructure Specialist
dvernon-6gMbXkmN5X7mEV3UZ/***@public.gmane.org<mailto:dvernon-6gMbXkmN5X7mEV3UZ/***@public.gmane.org>
loyalistcollege.com<http://loyalistcollege.com/>

[Loyalist College]<http://www.loyalistcollege.com/>[Facebook]<https://www.facebook.com/loyalistcollege>[Twitter]<https://twitter.com/loyalistcollege>

[Kevin Foote]

Post by Dave Vernon
Hello again,
As you know, yesterday was an exciting day for me, getting my first Shibboleth project running in my dev environment. My users are held in a Microsoft Active Directory (2008 R2 DC’s, 2003 functional level). I was aware that the default search base is CN=Users so I had put my test user there.
Today I went to expand that and I’ve run into issues. I’d like to be able to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca , so I edited my attribute-resolver.xml file on my IdP, restarted the service, and tested. I found that it wasn’t working – users NOT in the cn=users container were rejected by Shib, and my test user in the cn=users container was authenticated by Shib but rejected by the resource I’m protecting (remote_user not set)

….


And a snip from my idp-process.log

javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn


Dave,

In the IdP authentication and resolving attributes are two different functions.
Both are handled by the vt-ldap package but through different means..
Recall during setup you configured authentication in the “login.config” file while you configured
attribute resolution in the “attribute-resolver.xml” file

--------
thanks
kevin.foote

[Dave Vernon]

Thanks Kevin,

I missed the login.config file! That's what I needed. I've updated my files and things are working great.

Dave Vernon
Technology Infrastructure Specialist
dvernon-6gMbXkmN5X7mEV3UZ/***@public.gmane.org
loyalistcollege.com




-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On Behalf Of Kevin Foote
Sent: Tuesday, October 07, 2014 1:33 PM
To: Shib Users
Subject: Re: Shib / ldap search base

Post by Dave Vernon
Hello again,
As you know, yesterday was an exciting day for me, getting my first Shibboleth project running in my dev environment. My users are held in a Microsoft Active Directory (2008 R2 DC's, 2003 functional level). I was aware that the default search base is CN=Users so I had put my test user there.
Today I went to expand that and I've run into issues. I'd like to be
able to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca ,
so I edited my attribute-resolver.xml file on my IdP, restarted the
service, and tested. I found that it wasn't working - users NOT in
the cn=users container were rejected by Shib, and my test user in the
cn=users container was authenticated by Shib but rejected by the
resource I'm protecting (remote_user not set)

....


And a snip from my idp-process.log

javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn


Dave,

In the IdP authentication and resolving attributes are two different functions.
Both are handled by the vt-ldap package but through different means..
Recall during setup you configured authentication in the "login.config" file while you configured attribute resolution in the "attribute-resolver.xml" file

--------
thanks
kevin.foote

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Farzan Qureshi]

Hi Dave,

Would you mind sharing your code in login.config that how you are defining
multiple search base?

I have to achieve same scenario.

Kind regards,

Farzan Qureshi
------------------
Network Administrator & Helpdesk support
Rosmini College

Post by Dave Vernon
Thanks Kevin,
I missed the login.config file! That's what I needed. I've updated my
files and things are working great.
Dave Vernon
Technology Infrastructure Specialist
loyalistcollege.com
-----Original Message-----
On Behalf Of Kevin Foote
Sent: Tuesday, October 07, 2014 1:33 PM
To: Shib Users
Subject: Re: Shib / ldap search base

Post by Dave Vernon
Hello again,
As you know, yesterday was an exciting day for me, getting my first

Shibboleth project running in my dev environment. My users are held in a
Microsoft Active Directory (2008 R2 DC's, 2003 functional level). I was
aware that the default search base is CN=Users so I had put my test user
there.

Post by Dave Vernon
Today I went to expand that and I've run into issues. I'd like to be
able to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca ,
so I edited my attribute-resolver.xml file on my IdP, restarted the
service, and tested. I found that it wasn't working - users NOT in
the cn=users container were rejected by Shib, and my test user in the
cn=users container was authenticated by Shib but rejected by the
resource I'm protecting (remote_user not set)

....
And a snip from my idp-process.log
javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn
Dave,
In the IdP authentication and resolving attributes are two different functions.
Both are handled by the vt-ldap package but through different means..
Recall during setup you configured authentication in the "login.config"
file while you configured attribute resolution in the
"attribute-resolver.xml" file
--------
thanks
kevin.foote
--
To unsubscribe from this list send an email to
--
To unsubscribe from this list send an email to

--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager (
admin-***@public.gmane.org). Please note that any views or opinions presented
in this email are solely those of the author and do not necessarily
represent those of the company. Finally, the recipient should check this
email and any attachments for the presence of viruses. Rosmini College
accepts no liability for any damage caused by any virus transmitted by this
email.

[Dave Vernon]

Absolutely!

This is my login.config


edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="horus.ADS.LOYALISTCOLLEGE.CA"
port="3268"
base="DC=ads,DC=loyalistcollege,DC=ca"
tls="false"
serviceCredential="removed from post”
userRoleAttribute="sAMAccountName"
serviceUser="***@ads.loyalistcollege.ca"
subtreeSearch = "true"
userField="samAccountName";



(Where “horus” is a global catalog)


And then in addition my attribute-resolver is set to match

<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc"
useStartTLS="false"
ldapURL="ldap://horus.ADS.LOYALISTCOLLEGE.CA:3268" baseDN="DC=ads,DC=loyalistcollege,DC=ca" principal="***@ads.loyalistcollege.ca"
principalCredential="removed from post">
<FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</FilterTemplate>

<!-- We rely on the uniqueness of the objectSid. But it is binary so we *must* make it so -->
<LDAPProperty name="java.naming.ldap.attributes.binary" value="objectSid"/>
<!-- If we are following from the GC we need thus on -->
<LDAPProperty name="java.naming.referral" value="follow"/>

</resolver:DataConnector>



Once I made those changes, and restarted the service, I am able to login with any users in my AD domain, regardless of where the user is.

Dave Vernon
Technology Infrastructure Specialist
***@loyalistc.on.ca<mailto:***@loyalistc.on.ca>
loyalistcollege.com<http://loyalistcollege.com/>

[Loyalist College]<http://www.loyalistcollege.com/>[Facebook]<https://www.facebook.com/loyalistcollege>[Twitter]<https://twitter.com/loyalistcollege>

From: users-***@shibboleth.net [mailto:users-***@shibboleth.net] On Behalf Of Farzan Qureshi
Sent: Tuesday, October 07, 2014 2:48 PM
To: Shib Users
Subject: RE: Shib / ldap search base


Hi Dave,

Would you mind sharing your code in login.config that how you are defining multiple search base?

I have to achieve same scenario.

Kind regards,

Farzan Qureshi
------------------
Network Administrator & Helpdesk support
Rosmini College

On 8/10/2014 6:53 AM, "Dave Vernon" <***@loyalistcollege.com<mailto:***@loyalistcollege.com>> wrote:
Thanks Kevin,

I missed the login.config file! That's what I needed. I've updated my files and things are working great.

Dave Vernon
Technology Infrastructure Specialist
***@loyalistc.on.ca<mailto:***@loyalistc.on.ca>
loyalistcollege.com<http://loyalistcollege.com>




-----Original Message-----
From: users-***@shibboleth.net<mailto:users-***@shibboleth.net> [mailto:users-***@shibboleth.net<mailto:users-***@shibboleth.net>] On Behalf Of Kevin Foote
Sent: Tuesday, October 07, 2014 1:33 PM
To: Shib Users
Subject: Re: Shib / ldap search base

Post by Dave Vernon
Hello again,
As you know, yesterday was an exciting day for me, getting my first Shibboleth project running in my dev environment. My users are held in a Microsoft Active Directory (2008 R2 DC's, 2003 functional level). I was aware that the default search base is CN=Users so I had put my test user there.
Today I went to expand that and I've run into issues. I'd like to be
able to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca ,
so I edited my attribute-resolver.xml file on my IdP, restarted the
service, and tested. I found that it wasn't working - users NOT in
the cn=users container were rejected by Shib, and my test user in the
cn=users container was authenticated by Shib but rejected by the
resource I'm protecting (remote_user not set)

....


And a snip from my idp-process.log

javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn


Dave,

In the IdP authentication and resolving attributes are two different functions.
Both are handled by the vt-ldap package but through different means..
Recall during setup you configured authentication in the "login.config" file while you configured attribute resolution in the "attribute-resolver.xml" file

--------
thanks
kevin.foote

[Farzan Qureshi]

Hi Dave Vernon,

Thanks for the detailed response. Actually I was thinking you are querying
multiple base DNs. Actually I don't want to use top level AD forest. I want
to keep it restricted to three or four OUs. But I believe in your case you
are using top level base DN and not multiple search base.

I would be glad if someone in the community is using multiple search base.

Thanks for your help :-)

And thanks David for your response.

Kind regards,
Farzan

Post by Dave Vernon
Absolutely!
This is my login.config
edu.vt.middleware.ldap.jaas.LdapLoginModule required
host="horus.ADS.LOYALISTCOLLEGE.CA"
port="3268"
base="DC=ads,DC=loyalistcollege,DC=ca"
tls="false"
serviceCredential="removed from post”
userRoleAttribute="sAMAccountName"
subtreeSearch = "true"
userField="samAccountName";
(Where “horus” is a global catalog)
And then in addition my attribute-resolver is set to match
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
useStartTLS="false"
ldapURL="ldap://horus.ADS.LOYALISTCOLLEGE.CA:3268"
baseDN="DC=ads,DC=loyalistcollege,DC=ca" principal="
principalCredential="removed from post">
<FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</FilterTemplate>
<!-- We rely on the uniqueness of the objectSid. But it is binary
so we *must* make it so -->
<LDAPProperty name="java.naming.ldap.attributes.binary" value="objectSid"/>
<!-- If we are following from the GC we need thus on -->
<LDAPProperty name="java.naming.referral" value="follow"/>
</resolver:DataConnector>
Once I made those changes, and restarted the service, I am able to login
with any users in my AD domain, regardless of where the user is.
*Dave Vernon*
*Technology Infrastructure Specialist*
loyalistcollege.com
Facebook] <https://www.facebook.com/loyalistcollege>[image: Twitter]
<https://twitter.com/loyalistcollege>
*On Behalf Of *Farzan Qureshi
*Sent:* Tuesday, October 07, 2014 2:48 PM
*To:* Shib Users
*Subject:* RE: Shib / ldap search base
Hi Dave,
Would you mind sharing your code in login.config that how you are defining
multiple search base?
I have to achieve same scenario.
Kind regards,
Farzan Qureshi
------------------
Network Administrator & Helpdesk support
Rosmini College
Thanks Kevin,
I missed the login.config file! That's what I needed. I've updated my
files and things are working great.
Dave Vernon
Technology Infrastructure Specialist
loyalistcollege.com
-----Original Message-----
On Behalf Of Kevin Foote
Sent: Tuesday, October 07, 2014 1:33 PM
To: Shib Users
Subject: Re: Shib / ldap search base

Post by Dave Vernon
Hello again,
As you know, yesterday was an exciting day for me, getting my first

Shibboleth project running in my dev environment. My users are held in a
Microsoft Active Directory (2008 R2 DC's, 2003 functional level). I was
aware that the default search base is CN=Users so I had put my test user
there.

Post by Dave Vernon
Today I went to expand that and I've run into issues. I'd like to be
able to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca ,
so I edited my attribute-resolver.xml file on my IdP, restarted the
service, and tested. I found that it wasn't working - users NOT in
the cn=users container were rejected by Shib, and my test user in the
cn=users container was authenticated by Shib but rejected by the
resource I'm protecting (remote_user not set)

....
And a snip from my idp-process.log
javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn
Dave,
In the IdP authentication and resolving attributes are two different functions.
Both are handled by the vt-ldap package but through different means..
Recall during setup you configured authentication in the "login.config"
file while you configured attribute resolution in the
"attribute-resolver.xml" file
--------
thanks
kevin.foote
--
To unsubscribe from this list send an email to
--
To unsubscribe from this list send an email to
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
presented in this email are solely those of the author and do not
necessarily represent those of the company. Finally, the recipient should
check this email and any attachments for the presence of viruses. *Rosmini
College* accepts no liability for any damage caused by any virus
transmitted by this email.
--
To unsubscribe from this list send an email to

--
*Farzan Qureshi* | Network Administrator & Help-desk Support | Rosmini
College | (09) 487 0 530
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager (
admin-***@public.gmane.org). Please note that any views or opinions presented
in this email are solely those of the author and do not necessarily
represent those of the company. Finally, the recipient should check this
email and any attachments for the presence of viruses. Rosmini College
accepts no liability for any damage caused by any virus transmitted by this
email.

[Peter Schober]

Post by Farzan Qureshi
Thanks for the detailed response. Actually I was thinking you are querying
multiple base DNs. Actually I don't want to use top level AD forest. I want
to keep it restricted to three or four OUs. But I believe in your case you
are using top level base DN and not multiple search base.

The LDAP protocol doesn't have a way to say "search for this in those
3 basedns". You (i.e., the LDAP client) would have to issue 3 seperate
searches in each of those basedns.

I'd probably make sure the service DN used to perform the search does
not have read/search access to the parts of the DIT you don't want it
to search. Then you could still have simple configuration on the
client side (and slightly more efficient than issueing multiple
identical searches with different search bases) but limit the IDP to
specific parts of the DIT.
(If you're performing anonymous binds during the search, well, don't
do that.)
-peter

[Farzan Qureshi]

Thanks Peter for your input. I agree with it and I will do it as suggested.

Post by Farzan Qureshi

Post by Farzan Qureshi
Thanks for the detailed response. Actually I was thinking you are

querying

Post by Farzan Qureshi
multiple base DNs. Actually I don't want to use top level AD forest. I

want

Post by Farzan Qureshi
to keep it restricted to three or four OUs. But I believe in your case

you

Post by Farzan Qureshi
are using top level base DN and not multiple search base.

The LDAP protocol doesn't have a way to say "search for this in those
3 basedns". You (i.e., the LDAP client) would have to issue 3 seperate
searches in each of those basedns.
I'd probably make sure the service DN used to perform the search does
not have read/search access to the parts of the DIT you don't want it
to search. Then you could still have simple configuration on the
client side (and slightly more efficient than issueing multiple
identical searches with different search bases) but limit the IDP to
specific parts of the DIT.
(If you're performing anonymous binds during the search, well, don't
do that.)
-peter
--
To unsubscribe from this list send an email to

--
*Farzan Qureshi* | Network Administrator & Help-desk Support | Rosmini
College | (09) 487 0 530
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager (
admin-***@public.gmane.org). Please note that any views or opinions presented
in this email are solely those of the author and do not necessarily
represent those of the company. Finally, the recipient should check this
email and any attachments for the presence of viruses. Rosmini College
accepts no liability for any damage caused by any virus transmitted by this
email.

[David Gersic]

I'm not using multiple search bases. For Shib, I have an LDAP directory where all objects are in OU=People so I don't need multiple search bases.

Post by Farzan Qureshi
Hi Dave,
Would you mind sharing your code in login.config that how you are defining
multiple search base?
I have to achieve same scenario.
Kind regards,
Farzan Qureshi
------------------
Network Administrator & Helpdesk support
Rosmini College

Post by Dave Vernon
Thanks Kevin,
I missed the login.config file! That's what I needed. I've updated my
files and things are working great.
Dave Vernon
Technology Infrastructure Specialist
loyalistcollege.com
-----Original Message-----
On Behalf Of Kevin Foote
Sent: Tuesday, October 07, 2014 1:33 PM
To: Shib Users
Subject: Re: Shib / ldap search base

Post by Dave Vernon
Hello again,
As you know, yesterday was an exciting day for me, getting my first

Shibboleth project running in my dev environment. My users are held in a
Microsoft Active Directory (2008 R2 DC's, 2003 functional level). I was
aware that the default search base is CN=Users so I had put my test user
there.

Post by Dave Vernon
Today I went to expand that and I've run into issues. I'd like to be
able to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca ,
so I edited my attribute-resolver.xml file on my IdP, restarted the
service, and tested. I found that it wasn't working - users NOT in
the cn=users container were rejected by Shib, and my test user in the
cn=users container was authenticated by Shib but rejected by the
resource I'm protecting (remote_user not set)

....
And a snip from my idp-process.log
javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn
Dave,
In the IdP authentication and resolving attributes are two different functions.
Both are handled by the vt-ldap package but through different means..
Recall during setup you configured authentication in the "login.config"
file while you configured attribute resolution in the
"attribute-resolver.xml" file
--------
thanks
kevin.foote
--
To unsubscribe from this list send an email to
--
To unsubscribe from this list send an email to

--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager (
in this email are solely those of the author and do not necessarily
represent those of the company. Finally, the recipient should check this
email and any attachments for the presence of viruses. Rosmini College
accepts no liability for any damage caused by any virus transmitted by this
email.

[Kevin Foote]

Post by David Gersic
I'm not using multiple search bases. For Shib, I have an LDAP directory where all objects are in OU=People so I don't need multiple search bases.

Too many Daves on this thread..

For Seuss fans :-P

<http://www.poetryfoundation.org/poem/171612>

--------
thanks
kevin.foote

[David Gersic]

Post by Dave Vernon
Hello again,
As you know, yesterday was an exciting day for me, getting my first
Shibboleth project running in my dev environment. My users are held in a
Microsoft Active Directory (2008 R2 DC's, 2003 functional level). I was
aware that the default search base is CN=Users so I had put my test user
there.

If you specify the base DN to search, then the default shouldn't matter.

Post by Dave Vernon
Today I went to expand that and I've run into issues. I'd like to be able
to search from the root of my AD dc=ad,dc=loyalistcollege,dc=ca , so I edited
my attribute-resolver.xml file on my IdP, restarted the service, and tested.

That should work. If you use something like OpenLDAP's 'ldapsearch' to replicate the search, using that search base and the same filter you're using for Shib, what do you get back?

Post by Dave Vernon
I found that it wasn't working - users NOT in the cn=users container were
rejected by Shib, and my test user in the cn=users container was
authenticated by Shib but rejected by the resource I'm protecting
(remote_user not set)

Rejected how? What message(s)?

Post by Dave Vernon
I checked the documentation I see the common cause seems to revolve around
refers. The docs say that I need to set <LDAPProperty
name="java.naming.referral" value="follow"/> , as it is 'ignore' by default.
I think that's actually old information because I can verify that in my
instance it was set to 'follow' by default.

If you're binding to a DC, searching from the domain root, then you shouldn't be hitting any referrals anyway.

Post by Dave Vernon
The other fix is to search a GC instead - which is not a problem for me
("horus" is a GC). I changed my ldapURL to use port 3268 (plain old) but I'm
still getting the same results. If I move a user into the cn=users container
they work, but if they aren't there, they won't authenticate.

Sorry, no idea about GCs here. I just bind to a DC, specify a search base and filter, and away we go.

Post by Dave Vernon
Here is my attribute-resolver.xml
<resolver:DataConnector id="myLDAP" xsi:type="LDAPDirectory"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
useStartTLS="false"
ldapURL="ldap://horus.ADS.LOYALISTCOLLEGE.CA:3268"
baseDN="DC=ads,DC=loyalistcollege,DC=ca"
principalCredential="password removed for post">
<FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</FilterTemplate>
<!-- We rely on the uniqueness of the objectSid. But it is binary so
we *must* make it so -->
<LDAPProperty name="java.naming.ldap.attributes.binary" value="objectSid"/>
<!-- If we are following from the GC we need thus on -->
<LDAPProperty name="java.naming.referral" value="follow"/>
</resolver:DataConnector>
And a snip from my idp-process.log
javax.security.auth.login.LoginException: Cannot authenticate dn, invalid dn

IIRC, you can turn the logging level up on the LDAP resolutions to see what's going on. See logging.xml. Crank it up to INFO or DEBUG, then look in the log file. If you're getting "Cannot authenticate dn, invalid dn" it would be helpful to know what DN the resolver is trying to use.

Post by Dave Vernon
Any thoughts? I also read that I could stack multiple searches, which would
also work for me ( I only have 3 or 4 OUs where users are) so I tried
changing the base path to a specific OU where a user is, but I was also
unable to authenticate.

I think I read that, too, but I wouldn't bother with it. If the search from the domain root does what you want, then building something else would be suboptimal for you anyway.