IDPv3 Attribute Resolver help

Tue Nov 8 07:05:44 EST 2016

On 07/11/16 14:03, Rod Widdowson wrote:
>> I'm having an trouble getting the Attribute resolved to work with Active
>> Directory. I'm trying to pass through a handful of required attributes,
>> but whatever I do those attributes are never sent. Are there any step by
>> step guides on how to get this to work?
> 
> I'm assuming that you have started by reading
> 
> https://wiki.shibboleth.net/confluence/display/IDP30/AttributeResolverConfiguration

>> The immediate problem seems to be the LDAP dataconnector in
>> attribute-resolver.xml, which is complaining about the lack of a
>> trustCertificate. What is this and how do I set one up? 
> 
> And then 
> 
> https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector , 
> 
> https://wiki.shibboleth.net/confluence/display/IDP30/StartTLSAuthenticationCredential
> 
> specifically 
> 

Yes, I have been through all the documentation on the shibboleth wiki,
to be honest I've not found it to be very helpful. I have also googled
extensively. The problem is that while the docs explain the various
elements in isolation, nothing I have found gives the sequence of steps
necessary to get a typical IDPv3 to AD connection working. These
documents may exist, but I have failed to find them despite hours of
searching and I was hoping that somebody here could point me to such a
document.

eg, the document:

https://wiki.shibboleth.net/confluence/display/IDP30/StartTLSAuthenticationCredential

Only tells me how to configure a certificate file I already have so that
Shibboleth can use it, but it doesn't tell me what I have to do at the
AD end to obtain/configure the certificate so that AD knows about it as
well. I'm not dealing with the AD server side of this, but I'll ask the
person who is to look for TLS certificate settings. However, any
pointers on where to look for these settings would be much appreciated.

> https://wiki.shibboleth.net/confluence/display/IDP30/StartTLSAuthenticationCredential
> Alternatively,
>> since this is only intended as a test system, can I disable the
>> requirement for such a certificate?
> 
> Check out the section on properties in the second reference
> 
> "idp.attribute.resolver.LDAP.useStartTLS"

I've already got this set to false, but that doesn't stop the error
relating to a lack of certificate.

>> Also, since I already have a trust credential set up to enable the basic
>> authentication to work, what is the point of this certificate? I would
>> have expected the trust credential to be sufficient.
> 
> This is about ensuring the credibility and security of the connection you make to AD.  It has nothing to do with the security or
> credibility of you connection to the SPs.

The bind credential I have set up was for the connection between the IDP
and AD, (using idp.authn.LDAP.bindDN  and
idp.authn.LDAP.bindDNCredential which I thought was for the connection
between the IDP and AD. I used the wrong term when I said "trust
credential" which may have confused things.

On 07/11/16 14:09, Peter Schober wrote:
> Logging is key here, and data not being sent is another, later step.
> The logs (on DEBUG) will tell you exactly what attributes have been
> resolved, with how many values, and whether or why not they will be
> released.

Hmm, I originally had DEBUG logging turned on and I was advised in an
earlier reply on this list to turn it off because it was too noisy and
didn't provide much useful information for non-developers.

>
> If your LDAP server services requests without any transport layer
> security at all you could probably set both useStartTLS and useSSL to
> false as well as supply an ldap:// URL for the server.

Both are set to false and I'm using ldap:// in the URL, but I'm still
getting a fail when the LDAP resolver is set up telling me the
certificate path is invalid:

2016-11-08 11:53:14,600 - ERROR
[net.shibboleth.idp.profile.spring.relyingparty.security.credential.impl.X509ResourceCredentialFactoryBean:129]
- null: could not decode CertificateFile at class path resource
[undefined]: {}
java.io.FileNotFoundException: class path resource [undefined] cannot be
resolved to URL because it does not exist
        at
org.springframework.core.io.ClassPathResource.getURL(ClassPathResource.java:187)
2016-11-08 11:53:14,620 - WARN
[net.shibboleth.ext.spring.context.FilesystemGenericApplicationContext:545]
- Exception encountered during context initialization - cancelling
refresh attempt:
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'myLDAP': Cannot create inner bean '(inner
bean)#6aeebb54' of type [org.ldaptive.DefaultConnectionFactory] while
setting bean property 'connectionFactory'; nested exception is

> Personally I'd only do that in conjunction with SASL binds that
> provide a security factor (not "PLAIN"), and certainly not with simple
> binds, to prevent at least passwords from going over the wire in the
> clear, but your call.
>
>> Also, since I already have a trust credential set up to enable the
>> basic authentication to work, what is the point of this certificate?
>> I would have expected the trust credential to be sufficient.
>
> Most deployers will want to protect data (and potentially passwords)
> from being transmitted in the clear, which usually means TLS.
> The parameter you ask about (and idp.authn.LDAP.authenticator more
> specifically) are for fine-tuning the technical trust from the IDP as
> LDAP client to the LDAP server.

Ok, that makes more sense. I had assumed that the security just work
without the need to manually exchange certificates, as is the case for
ssh connections. However, the question remains, either how do I get the
certificate I need here out of AD or how do I turn off the need for it?

Thanks again!

Tim W

-- 
Tim Williams BSc MSc MBCS
AutoTrain
58 Jacoby Place
Priory Road
Edgbaston
Birmingham
B5 7UW
United Kingdom

Web : http://www.autotrain.org, http://www.utrain.info
Tel : +44 (0)844 487 4117

AutoTrain is a trading name of EuroMotor-AutoTrain LLP
Registered in the United Kingdom, number: OC317070.