[Shib-Users] Problem returning Attributes from AD (LDAP connector)
Nuno Gonç alves
I'm trying to get attributes from an MS Active Directory using the LDAP
connector.
If I use a global catalog all goes ok smoothly, still I'm trying to make
the other way around and going directly to the AD.
Read about it on
https://spaces.internet2.edu/display/SHIB2/ResolverLDAPDataConnector and
followed the instructions on referrals
<LDAPProperty name="java.naming.referral" value="follow"/>
Anyway I'm getting this error in idp-process.log:
11:02:54.296 ERROR
[edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:837]
- An error occured when attempting to search the LDAP:
{java.naming.provider.url=ldap://IP_ADDRESS:389,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory}
javax.naming.PartialResultException: Unprocessed Continuation Reference(s)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2763)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
I have checked the connector and I only have the vt-ldap.2.8.1.jar in
the lib directories in shibboleth, tomcat and JDK.
Did anyone had this behaviour ?
The authentication process is OK, I authenticate with no problems.
Other strange thing is if I use the ldapsearch cmd line to the AD it
works perfectly :P
Do you think that It might be related to the connector ?
In attribute-resolver.xml I have the following:
<resolver:DataConnector id="ldapConnector" xsi:type="LDAPDirectory"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://IP_ADDRESS:389"
baseDN="dc=dc_value,dc=dc_value,dc=dc_value"
principal="principal@ldap"
principalCredential="password">
<FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</FilterTemplate>
Best regards to you all and thanks for your time reading this
Nuno
Isaac
the log snippet you posted.
Here is a sample from the error log after the configuration change,
but when I had a separate issue (notice java.naming.referral=follow
which is missing from your log):
An error occured when attempting to search the LDAP:
{java.naming.provider.url=ldap://IP_ADDRESS:389,
java.naming.factory.initial=com.sun.jndi.ldap.LdapCtxFactory,
java.naming.referral=follow}
Are you sure the LDAPProperty element is inside the resolver? Also,
did you restart tomcat after making the change?
<resolver:DataConnector id="ldapConnector" xsi:type="LDAPDirectory"
xmlns="urn:mace:shibboleth:2.0:resolver:dc"
ldapURL="ldap://IP_ADDRESS:389"
baseDN="dc=dc_value,dc=dc_value,dc=dc_value"
principal="principal@ldap"
principalCredential="password">
<FilterTemplate>
<![CDATA[
(sAMAccountName=$requestContext.principalName)
]]>
</FilterTemplate>
<LDAPProperty name="java.naming.referral" value="follow"/>
</resolver>
One more thing. In my configuration I was unable to use the
principal@ldap format for the principal, instead I had to use the full
dn. Otherwise it threw another exception.
Nuno Gonçalves
Yes, I added the follow parameter and the connection is all OK! The very very strange thing is that, It only works if I give a subtree to search in in the baseDN :(
for better understanding the problem , the AD structure where I need to search is something like
root (dc=dc_value,dc=dc_value,dc=dc_value)
| | |
A B C
If I specify the following conf (Note the ou=A in baseDN) it works for the branch A:
The problem here is that I need to search on branches A, B and C, but using the root causes an ldap search error in idp-process.log :(
With ldapsearch using the root tree:
ldapsearch -h ldap_ip_address -p 389 -D principal -w principalCredential "dc=corp,dc=fccn,dc=pt" "sAMAccountName=user_to_search"
It works fine ! That's why I can't understand why doesn't work on the attribute-resolver.xml :(
Is there anyway of specifying the several OU in baseDN since it seems that it doesn't work using the root ?
thanks once again for all your precious hints
best regards to you all
Nuno
-- ______________________________________________ Nuno Gonçalves FCCN Av. do Brasil, nº 101 1700-066 Lisboa tel: +351 218 440 100 - fax: +351 218 472 167 email|SIP: nu...@fccn.pt http://www.fccn.pt ______________________________________________ --- Aviso de Confidencialidade Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218 440 100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218 440 100 and delete it immediately. ---
Brent Putman
Nuno Gonçalves wrote:
>
>
> The problem here is that I need to search on branches A, B and C, but
> using the root causes an ldap search error in idp-process.log :(
This sounds exactly like the problem that is discussed in the later part
of the Microsoft Active Directory Deployment Notes section here:
https://spaces.internet2.edu/display/SHIB2/ResolverLDAPDataConnector
You can't just turn on referrals. Your client (here the LDAP data
connector) has to actually be able to successfully follow the referrals,
or you will get errors.
>
> With ldapsearch using the root tree:
> ldapsearch -h ldap_ip_address -p 389 -D principal -w
> principalCredential "dc=corp,dc=fccn,dc=pt"
> "sAMAccountName=user_to_search"
As suggested in the wiki, look at the docs for your ldapsearch utility
for a verbose or debug option, and also turn off following of referrals,
if it does it by default. The verbose/debug output usually indicates
exactly what referrals are being returned. The most common problem is
issues with LDAP server hostnames and DNS for those not being resolveable.
>
> It works fine ! That's why I can't understand why doesn't work on the
> attribute-resolver.xml :(
Are you running the query on the same machine, with same DNS config and
functionality as the IdP machine, or different?
It may in fact not be working from the command-line, the ldapsearch
utility may just ignore referrals unless you tell it explicitly to
follow them.
>
> Is there anyway of specifying the several OU in baseDN since it seems
> that it doesn't work using the root ?
No, I don't think so, but you could of course specify multiple LDAP data
connectors, each with a separate baseDN. That means more queries and
network round-trips, and more overhead, so you should probably try and
figure why the referrals are failing.