Which handler LDAP SSO - NOW kerberos integration

Morris, Andi amorris at cardiffmet.ac.uk
Thu Nov 13 10:12:05 EST 2014 

Thanks for that Douglas, I'll be sure to add that in once I have this all working.

I'm now seeing more progress, but still issues.

On sp.testshib.org I get:
opensaml::FatalProfileException at (https://sp.testshib.org/Shibboleth.sso/SAML2/POST)

Message was signed, but signature could not be verified.

I know this points to the certificate not matching, but I've checked the SP logs and it is the same signature that is in my relying party.

2014-11-13 09:58:33 DEBUG OpenSAML.MessageDecoder.SAML2 [3513]: extracting issuer from SAML 2.0 protocol message
2014-11-13 09:58:33 DEBUG OpenSAML.MessageDecoder.SAML2 [3513]: message from (https://idp.dev.cardiffmet.ac.uk/idp/shibboleth)
2014-11-13 09:58:33 DEBUG OpenSAML.MessageDecoder.SAML2 [3513]: searching metadata for message issuer...
2014-11-13 09:58:33 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [3513]: evaluating message flow policy (replay checking on, expiration 60)
2014-11-13 09:58:33 DEBUG XMLTooling.StorageService [3513]: inserted record (_4b2993720c9bd10984839670e7088021) in context (MessageFlow) with expiration (1415890953)
2014-11-13 09:58:33 DEBUG Shibboleth.SSO.SAML2 [3513]: processing message against SAML 2.0 SSO profile
2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]: resolved 0 certificate(s)
2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: key algorithm didn't match ('AES' != 'RSA')
2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: key algorithm didn't match ('AES' != 'RSA')
2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: key algorithm didn't match ('AES' != 'RSA')
2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]: resolving ds:X509Certificate
2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]: resolved 1 certificate(s)
2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: credential name(s) didn't overlap
2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: keys didn't match
2014-11-13 09:58:33 DEBUG Shibboleth.SSO.SAML2 [3513]: decrypted Assertion: <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" ID="_2f0d0ae45f56954adb58fdb2bff814de" IssueInstant="2014-11-13T14:58:33.118Z" Version="2.0"><saml2:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">https://idp.dev.cardiffmet.ac.uk/idp/shibboleth</saml2:Issuer><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><ds:Reference URI="#_2f0d0ae45f56954adb58fdb2bff814de"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/><ds:DigestValue>LuHUxMP8d27OrPqkuuO8tB3HRlQ=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>Ft6nGEa4dmrqL085w4KU2g3h5rdWv6eN25VE6C7WbzGXBNSCqxpFOcQBWh3YVjuz12ERBEiqh+jumqph6cuJSxFBehovZ23Tax24tg4P9/+KsMEsRf50w9O9HTPAtYOQD9yP7VKuJ48UNEWeOc7A8r9eb68rzLtS11cf20YCrGONuIl5TzmQrJ3h+cvbvEfCvUOXEzsbdlxSNb273uKhwk6m7OASjeq8Z/1AagVhHhb+w+mFbKtvqCtsa1FTlV7tVfzebPLft1DBCb9eg2ebSDnSVviyKJIFNE4PF2v76B1WemgVxwU/U2mEmwPIP6q+zFeCoOzl/NHzxOaP6o4mdw==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIIDTDCCAjSgAwIBAgIVAN88L4R+0kz0wXSzNKse0EpMQso3MA0GCSqGSIb3DQEBBQUAMCMxITAf
BgNVBAMMGGlkcC5kZXYuY2FyZGlmZm1ldC5hYy51azAeFw0xNDExMTIxMzEzMzhaFw0zNDExMTIx
MzEzMzhaMCMxITAfBgNVBAMMGGlkcC5kZXYuY2FyZGlmZm1ldC5hYy51azCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAKVu2OQ1YaOL42l15dANGivbm2fno6XCIGz0DQVyXpsPdmb7LYpi
gBlZH3MoQzEbcN1TmL6YAKekEGJ8ruH+NkqZ6l+vyqSA1lnWjMeOfJ3AYcQMm1S7QmSC6xyuD3lo
5mHgqmHj91hHH0tuHmZLZJzGef2CT/fOI164OanBwYxyaiNYzxMuX9ew2Eer0m8y6YYBByvFTYuy
LBQKAE87lUqUYJQ+LUUhTNp6Ap2ZEdPH8ZFKoG7L+F3ty9Woyn7nyfYitxkCRKtsacaiJh9Nz34O
Oe3nXVAnm2XqxFOE4K53XrW8Mwixbw7utuOhz4FPXXxisay1/swbNO/v7pj05KECAwEAAaN3MHUw
HQYDVR0OBBYEFAlK7mnvW1R58aIsvQMNLjChoiP/MFQGA1UdEQRNMEuCGGlkcC5kZXYuY2FyZGlm
Zm1ldC5hYy51a4YvaHR0cHM6Ly9pZHAuZGV2LmNhcmRpZmZtZXQuYWMudWsvaWRwL3NoaWJib2xl
dGgwDQYJKoZIhvcNAQEFBQADggEBAJ8faMAT8CUPzHakBGGRfGMtVyWn5Qj1BXwTxqsPh/a4RFtn
zpWf+PfMRTAIvKFa6LpqU+A8ObZ2aIN93AqT6TniJmxcoagLeUm+VXD6KJMAtnugZWoz8WOpMzxo
MN98WRIXYslgGkoKDYrW8zYnU7LS01dToneTfgRQZJ5Klnn5S45j1dZZI+Anl4/HUGgThzN9vQJi
mKB68eLdil6n1DMgP8z5A1cC9Ot28XRTI/kO7ykFtd6Q8yzjczBc7AZ3Ef382mX4Zzr7RZE2BrzF
1pU/c/Dld8pLc1YUpUxcfOuABgdih3vFwNgmlyXEOd6JsyRVe4fkLYy3B+KdXm4Tch4=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Subject><saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier="https://idp.dev.cardiffmet.ac.uk/idp/shibboleth" SPNameQualifier="https://sp.testshib.org/shibboleth-sp">_ee6f1b4caffb34e7ec9dd6196a48161c</saml2:NameID><saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmationData Address="192.168.42.42" InResponseTo="_f5f27cf7d9cab13afa6b246b63f42bc2" NotOnOrAfter="2014-11-13T15:03:33.118Z" Recipient="https://sp.testshib.org/Shibboleth.sso/SAML2/POST"/></saml2:SubjectConfirmation></saml2:Subject><saml2:Conditions NotBefore="2014-11-13T14:58:33.118Z" NotOnOrAfter="2014-11-13T15:03:33.118Z"><saml2:AudienceRestriction><saml2:Audience>https://sp.testshib.org/shibboleth-sp</saml2:Audience></saml2:AudienceRestriction></saml2:Conditions><saml2:AuthnStatement AuthnInstant="2014-11-13T14:58:33.104Z" SessionIndex="_53201c5ff6945bde10cf00907c3e855e"><saml2:SubjectLocality Address="192.168.42.42"/><saml2:AuthnContext><saml2:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</saml2:AuthnContextClassRef></saml2:AuthnContext></saml2:AuthnStatement></saml2:Assertion>
2014-11-13 09:58:33 DEBUG Shibboleth.SSO.SAML2 [3513]: extracting issuer from SAML 2.0 assertion
2014-11-13 09:58:33 DEBUG OpenSAML.SecurityPolicyRule.MessageFlow [3513]: evaluating message flow policy (replay checking on, expiration 60)
2014-11-13 09:58:33 DEBUG XMLTooling.StorageService [3513]: inserted record (_2f0d0ae45f56954adb58fdb2bff814de) in context (MessageFlow) with expiration (1415890953)
2014-11-13 09:58:33 DEBUG OpenSAML.SecurityPolicyRule.XMLSigning [3513]: validating signature profile
2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]: resolving ds:X509Certificate
2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]: resolved 1 certificate(s)
2014-11-13 09:58:33 DEBUG XMLTooling.KeyInfoResolver.Inline [3513]: resolved 0 CRL(s)
2014-11-13 09:58:33 DEBUG XMLTooling.CredentialCriteria [3513]: keys didn't match
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.ExplicitKey [3513]: unable to validate signature, no credentials available from peer
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: validating signature using certificate from within the signature
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: signature verified with key inside signature, attempting certificate validation...
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: checking that the certificate name is acceptable
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: adding to list of trusted names (https://idp.dev.cardiffmet.ac.uk/idp/shibboleth)
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: certificate subject: CN=idp.dev.cardiffmet.ac.uk
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: unable to match DN, trying TLS subjectAltName match
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: matched DNS/URI subjectAltName to a key name (https://idp.dev.cardiffmet.ac.uk/idp/shibboleth)
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: performing certificate path validation...
2014-11-13 09:58:33 DEBUG XMLTooling.TrustEngine.PKIX [3513]: failed to validate certificate chain using supplied PKIX information
2014-11-13 09:58:33 ERROR OpenSAML.SecurityPolicyRule.XMLSigning [3513]: unable to verify message signature with supplied trust engine
2014-11-13 09:58:33 WARN Shibboleth.SSO.SAML2 [3513]: detected a problem with assertion: Message was signed, but signature could not be verified.
2014-11-13 09:59:25 INFO XMLTooling.StorageService : purged 2 expired record(s) from storage

My IDP logs show:

14:58:23.219 - INFO [Shibboleth-Access:73] - 20141113T145823Z|192.168.42.42|idp.dev.cardiffmet.ac.uk:443|/profile/SAML2/Redirect/SSO|
14:58:23.230 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:297] - AutoLogin not active: redirecting to login page
14:58:23.230 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:262] - Redirecting to login page
14:58:23.230 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:218] - Redirecting to /login.jsp
14:58:23.232 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:105] - cookie '_idp_krb_autologin' created [value=false, maxage=31536000, path=/idp, secure=true, domain=null]
14:58:23.232 - INFO [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:249] - 'auto login' cookie sent.
14:58:28.053 - INFO [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:125] - kerberos idp servlet started
14:58:28.053 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:72] - HTTP: Returning response code '401'. Authorization header not found.
14:58:28.068 - INFO [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:125] - kerberos idp servlet started
14:58:28.069 - TRACE [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:77] - HTTP: Authorization header found.
14:58:28.069 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:87] - Validating GSS token. Realm: INTERNAL.UWIC.AC.UK
14:58:28.069 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:118] - Logging KDC 'INTERNAL.UWIC.AC.UK'.
14:58:33.091 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:127] - KDC Logging successful.
14:58:33.091 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:133] - Creating GSS context.
14:58:33.093 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:145] - GSS context created.
14:58:33.094 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:150] - Validating the GSS Token.
14:58:33.101 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbContextAcceptor:92] - Security context established.
14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:109] - Context established.
14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:117] - Principal: username at INTERNAL.UWIC.AC.UK
14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.HttpNegotiator:124] - HTTP: Returning response code '200' and the gssapi data to complet the context.
14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:164] - Returning PRINCIPAL_NAME_KEY=username at INTERNAL.UWIC.AC.UK
14:58:33.103 - TRACE [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:177] - Setting request attribute 'authnMethod' to 'urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos'
14:58:33.103 - DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginServlet:182] - Returning to Authentication Engine
14:58:33.116 - INFO [Shibboleth-Access:73] - 20141113T145833Z|192.168.42.42|idp.dev.cardiffmet.ac.uk:443|/profile/SAML2/Redirect/SSO|
14:58:33.138 - INFO [Shibboleth-Audit:1028] - 20141113T145833Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_f5f27cf7d9cab13afa6b246b63f42bc2|https://sp.testshib.org/shibboleth-sp|urn:mace:shibboleth:2.0:profiles:saml2:sso|https://idp.dev.cardiffmet.ac.uk/idp/shibboleth|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST|_4b2993720c9bd10984839670e7088021|username@INTERNAL.UWIC.AC.UK|urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos||_ee6f1b4caffb34e7ec9dd6196a48161c||

The wiki suggests that I'm either using the wrong certificates, or my idp is spoofing another one, but I really am not sure how that would have happened.

Cheers,
Andi

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E Engert
Sent: 13 November 2014 11:04
To: users at shibboleth.net
Subject: Re: Which handler LDAP SSO



On 11/13/2014 2:47 AM, Morris, Andi wrote:
> Cheers Douglas, that was helpful.
>
> I discovered that the keytab file was only readable by the apache user and not the tomcat user. I've chmod'd this so that only the tomcat user has access, and the Kerberos user is now authenticated.
>
>> With AD as ldap, you may want to add:
>> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
>> to not accept disabled accounts.
>
> Really interested in that. How would I plumb that in?

Your filter would look like:

  (&(|(mail=$requestContext.principalName)(&(samaccountname=${krb_principalname.get(0)})(msSFU30NisDomain=${krb_domain.get(0)})))(objectclass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))

>
> Cheers,
> Andi
>
> -----Original Message-----
> From: users-bounces at shibboleth.net 
> [mailto:users-bounces at shibboleth.net] On Behalf Of Douglas E Engert
> Sent: 12 November 2014 21:22
> To: users at shibboleth.net
> Subject: Re: Which handler LDAP SSO
>
>
>
> On 11/12/2014 8:08 AM, Morris, Andi wrote:
>> Ok, thanks Peter.
>> I'm getting somewhere with this, slowly and frustratingly so.
>>
>> I have Kerberos running between my idp box and my Active Directory servers, that was the easy bit.
>>
>> I've gone through https://crypt.ncl.ac.uk/login-gateway/docs/Shibboleth_SPNEGO_Setup.pdf up until the part where the login.jsp is modded to autodetect browsers, ip addresses and relying parties, as I don't think that's necessary for my site. I've also been cross referencing these against the documentation at https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login+Handler which had some confusing parts, but I think I've made it through the majority. I wasn't sure with the section at the beginning of the handler.xml in the wiki as it doesn't describe whether to add these new schemas, replace the old ones, and amend them for the shibboleth setup. I ended up putting:
>>
>>
>> <ph:ProfileHandlerGroup xmlns:ph="urn:mace:shibboleth:2.0:idp:profile-handler" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>                           xmlns:krb="http://www.switch.ch/aai/idp/kerberos" krb:schemalocation="http://www.switch.ch/aai/idp/kerberos classpath:/schema/kerberos-login-handler.xsd"
>>
>> xsi:schemaLocation="urn:mace:shibboleth:2.0:idp:profile-handler
>> classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd">
>>
>> Is this correct?
>
> Before I retired, we used something like this, that added the krb5 and x509 handlers to the original user/password group Realm/AD dommain name changed to OURREALM.EDU. IDP on RedHat.
>
>
> <ph:ProfileHandlerGroup xmlns:ph="urn:mace:shibboleth:2.0:idp:profile-handler"
>          xmlns:x509="http://www.switch.ch/aai/idp/x509"
>          xmlns:krb="http://www.switch.ch/aai/idp/kerberos"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          
> xsi:schemaLocation="urn:mace:shibboleth:2.0:idp:profile-handler 
> classpath:/schema/shibboleth-2.0-idp-profile-handler.xsd 
> http://www.switch.ch/aai/idp/x509 
> classpath:/schema/x509-login-handler.xsd 
> http://www.switch.ch/aai/idp/kerberos 
> classpath:/schema/kerberos-login-handler.xsd">
>
> The later in the group:
>      <!-- Kerberos Idp -->
>       <ph:LoginHandler xsi:type="krb:KERBEROS"
>                     kerberosCfg="/etc/krb5.conf"
>                     customUnauthorized="/opt/shibboleth-idp-2.3.8/other/unauthorized.html"
>                     autoLoginDurantion="300"
>             loginPagePattern="/kerberos-login-try-first.jsp"
>             krbServletPattern="/Authn/Kerberos/Login"
>
>       <!-- LoginHandler optional attributes:
>                     kerberosCfg - kerberos configuration file
>                     customUnauthorized - custom html page for error 401 - Unauthorized. (e.g.: jar:/example/unauthorized.html)
>                     auto_login_durantion - auto login duration (seconds)
>                     loginPagePattern - (default: "/login.jsp") - path for login page
>                     krbServletPattern - (default: "/Authn/Kerberos") - path for kerberos login page
>       -->
>           <ph:AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</ph:AuthenticationMethod>
>           <krb:Realm domain="OURREALM.EDU">
>               <krb:principal>HTTP/idp.ourrealm.edu at OURREALM.EDU</krb:principal>
>               <krb:keytab>/etc/krb5.keytab.http</krb:keytab>
>           </krb:Realm>
>    </ph:LoginHandler>
>
>
>
>>
>> However the main part I'm getting stuck on is the configuration of the attribute resolver. When restarting tomcat I get the following in the idp-process.log:
>> 13:56:17.734 - INFO
>> [edu.internet2.middleware.shibboleth.common.config.BaseService:158] - 
>> Loading new configuration for service shibboleth.AttributeResolver
>> 13:56:17.790 - ERROR [edu.internet2.middleware.shibboleth.common.config.BaseService:188] - Configuration was not loaded for shibboleth.AttributeResolver service, error creating components.  The root cause of this error was: org.xml.sax.SAXParseException: Key 'DataConnectorAttributeDefinitionDependencyRef' with value 'HTTP/servername.cardiffmet.ac.uk' not found for identity constraint of element 'AttributeResolver'.
>>
>> Now clearly it doesn't like the prinicipal name here. attribute-resolver.conf has the following configuration for that part, as taken from https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login+Handler+-+Attribute+resolver:
>>       <resolver:DataConnector id="fhnwAdmLDAP"
>>           xsi:type="dc:LDAPDirectory"
>>           ldapURL="${ldap.address}"
>>           baseDN="OU=UserAccs,DC=internal,DC=domain,DC=ac,DC=uk"
>>           principal="${ldap.principal}"
>>           principalCredential="${ldap.credential}" >
>
> As noted in other responses, these do not look correct.
>
>>         <resolver:Dependency ref="HTTP/servername.cardiffmet.ac.uk" />
>>         <resolver:Dependency ref="INTERNAL.DOMAIN.AC.UK" />
>>           <dc:FilterTemplate>
>> <!--
>> (mail=$requestContext.principalName) - matches UsernamePassword 
>> Principal
>> &(samaccountname=${})(msSFU30NisDomain=${}) - matches Kerberos 
>> Principal
>
> Not the way we did it, but could be OK.
>
> With AD as ldap, you may want to add:
> (!(userAccountControl:1.2.840.113556.1.4.803:=2))
> to not accept disabled accounts.
>
> http://support.microsoft.com/kb/269181
>
>
>> -->
>>               <![CDATA[
>>                   (&(|(mail=$requestContext.principalName)(&(samaccountname=${krb_principalname.get(0)})(msSFU30NisDomain=${krb_domain.get(0)})))(objectclass=user))
>>               ]]>
>>           </dc:FilterTemplate>
>>           <dc:LDAPProperty name="java.naming.referral" value="follow"/>
>>       </resolver:DataConnector>
>>
>> What have I missed here.
>
> It is also not clear if your IDP is in the same DNS domain as the AD domain that your users are in.
> This can make it harder for a client to determine if it needs to do cross realm.
>
> HTTP/servername.cardiffmet.ac.uk implies IDP is 
> servername.cardiffmet.ac.uk
>
> You say this is the realm name, INTERNAL.DOMAIN.AC.UK which implies AD domain name is internal.domain.ac.uk.
>
>
>>
>> Thanks in advance for any help,
>> Andi
>>
>> -----Original Message-----
>> From: users-bounces at shibboleth.net
>> [mailto:users-bounces at shibboleth.net] On Behalf Of Peter Schober
>> Sent: 11 November 2014 13:03
>> To: users at shibboleth.net
>> Subject: Re: Which handler LDAP SSO
>>
>> * Morris, Andi <amorris at cardiffmet.ac.uk> [2014-11-11 13:44]:
>>> Thanks. I have UsernamePassword configured at the moment and I'm 
>>> having trouble getting the bind to work so that users can login, but 
>>> I'll continue to work on that.
>>
>> This is all within the JAAS config file, login.config, as per the Shib documentation.
>>
>>> However, when running against test shib I'm being shown a login 
>>> screen, as expected at the moment.
>>
>> Yes, 
>> https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUserAuthn
>> says
>>
>>     "Username/Password:
>>     Presents the user with an authentication page and then checks the
>>     entered username and password against an LDAP directory or Kerberos 5
>>     domain."
>>
>> So the UsernamePassword will generate HTML to collect credentials, and validate them via LDAP (or Kerberos, but that doesn't change the fact that a HTML form is rendered at the IDP).
>>
>>
>>> When I have the ldap running correctly will the users still be shown 
>>> this screen if they already currently have valid windows credentials
>>
>> Yes.
>>
>>> or will I need to configure this with Kerberos? What we have at the 
>>> moment is users being logged on without being prompted when they 
>>> access a shibboleth resource internally.
>>
>> You'll have to do something entirely different:
>>
>> https://wiki.shibboleth.net/confluence/display/SHIB2/Kerberos+Login+H
>> a
>> ndler
>>
>> The folks from Uni Newcastle have quite complete documentation for this, IIRC, if you (or your peers from the UKfederation) don't find anything better to offer try this:
>> https://www.google.com/search?q=newcastle+shib+SPNEGO
>> -peter
>> --
>> To unsubscribe from this list send an email to 
>> users-unsubscribe at shibboleth.net
>>
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net

More information about the users mailing list