Which handler LDAP SSO - NOW kerberos integration
Morris, Andi
amorris at cardiffmet.ac.uk
Tue Nov 18 11:39:57 EST 2014
I'm so close with this now, thanks to you guys for your help so far.
At the moment I have a username and password box appear when the with a button at the bottom when the user can click to send their Kerberos details. I'd like to automate this so that the Kerberos details are automatically used when the user accesses the page from a supported browser (IE). This is how we have this working in our prod environment with the remoteuser handler.
My login page is login.jsp which was copied from login_example.jsp.
I see the following in the log file:
DEBUG [ch.SWITCH.aai.idp.kerberos.KrbLoginHandler:297] - AutoLogin not active: redirecting to login page
However I can't see where in any of the Kerberos login config files that I can enable autologin.
Another question is, do I need to reinstall the application each time I make a change to anything within the shibinstall path folder? EG., /opt/shibboleth-identityprovider-2.4.3/src/main/webapp/login.jsp
Cheers,
Andi
-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Morris, Andi
Sent: 13 November 2014 16:03
To: 'Shib Users'
Subject: RE: Which handler LDAP SSO - NOW kerberos integration
Looking at the mailing list archives it appears I might need to wait for testshib to clear out my old metadata as I don't think I uploaded them with different filenames.
I'll likely look to install my own dev SP anyway that I can use in the future which will of course resolve that.
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 15:37
To: users at shibboleth.net
Subject: Re: Which handler LDAP SSO - NOW kerberos integration
You have gotten by the Kerberos part, this looks like a metadata problem, maybe someone else can look at it.
On 11/13/2014 9:12 AM, Morris, Andi wrote:
> 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:Canon
> icalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMeth
> od
> 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>Lu
> HUxMP8d27OrPqkuuO8tB3HRlQ=</ds:DigestValue></ds:Reference></ds:S
ig
>
> nedInfo><ds:SignatureValue>Ft6nGEa4dmrqL085w4KU2g3h5rdWv6eN25VE6C7WbzG
> XBNSCqxpFOcQBWh3YVjuz12ERBEiqh+jumqph6cuJSxFBehovZ23Tax24tg4P9/+KsMEsR
> f50w9O9HTPAtYOQD9yP7VKuJ48UNEWeOc7A8r9eb68rzLtS11cf20YCrGONuIl5TzmQrJ3
> h+cvbvEfCvUOXEzsbdlxSNb273uKhwk6m7OASjeq8Z/1AagVhHhb+w+mFbKtvqCtsa1FTl
> V7tVfzebPLft1DBCb9eg2ebSDnSVviyKJIFNE4PF2v76B1WemgVxwU/U2mEmwPIP6q+zFe
> CoOzl/NHzxOaP6o4mdw==</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:
> X509Certificate>MIIDTDCCAjSgAwIBAgIVAN88L4R+0kz0wXSzNKse0EpMQso3MA0GCS
> qGSIb3DQEBBQUAMCMxITAf
> BgNVBAMMGGlkcC5kZXYuY2FyZGlmZm1ldC5hYy51azAeFw0xNDExMTIxMzEzMzhaFw0zND
> ExMTIx
> MzEzMzhaMCMxITAfBgNVBAMMGGlkcC5kZXYuY2FyZGlmZm1ldC5hYy51azCCASIwDQYJKo
> ZIhvcN
> AQEBBQADggEPADCCAQoCggEBAKVu2OQ1YaOL42l15dANGivbm2fno6XCIGz0DQVyXpsPdm
> b7LYpi
> gBlZH3MoQzEbcN1TmL6YAKekEGJ8ruH+NkqZ6l+vyqSA1lnWjMeOfJ3AYcQMm1S7QmSC6x
> gBlZH3MoQzEbcN1TmL6YAKekEGJ8ruH+NkqZ6l+yuD3lo
> 5mHgqmHj91hHH0tuHmZLZJzGef2CT/fOI164OanBwYxyaiNYzxMuX9ew2Eer0m8y6YYBBy
> vFTYuy
> LBQKAE87lUqUYJQ+LUUhTNp6Ap2ZEdPH8ZFKoG7L+F3ty9Woyn7nyfYitxkCRKtsacaiJh
> LBQKAE87lUqUYJQ+LUUhTNp6Ap2ZEdPH8ZFKoG7L+9Nz34O
> Oe3nXVAnm2XqxFOE4K53XrW8Mwixbw7utuOhz4FPXXxisay1/swbNO/v7pj05KECAwEAAa
> N3MHUw
> HQYDVR0OBBYEFAlK7mnvW1R58aIsvQMNLjChoiP/MFQGA1UdEQRNMEuCGGlkcC5kZXYuY2
> FyZGlm
> Zm1ldC5hYy51a4YvaHR0cHM6Ly9pZHAuZGV2LmNhcmRpZmZtZXQuYWMudWsvaWRwL3NoaW
> Jib2xl
> dGgwDQYJKoZIhvcNAQEFBQADggEBAJ8faMAT8CUPzHakBGGRfGMtVyWn5Qj1BXwTxqsPh/
> a4RFtn
> zpWf+PfMRTAIvKFa6LpqU+A8ObZ2aIN93AqT6TniJmxcoagLeUm+VXD6KJMAtnugZWoz8W
> zpWf+PfMRTAIvKFa6LpqU+A8ObZ2aIN93AqT6TniJmxcoagLeUm+OpMzxo
> MN98WRIXYslgGkoKDYrW8zYnU7LS01dToneTfgRQZJ5Klnn5S45j1dZZI+Anl4/HUGgThz
> MN98WRIXYslgGkoKDYrW8zYnU7LS01dToneTfgRQZJ5Klnn5S45j1dZZI+N9vQJi
> mKB68eLdil6n1DMgP8z5A1cC9Ot28XRTI/kO7ykFtd6Q8yzjczBc7AZ3Ef382mX4Zzr7RZ
> E2BrzF
> 1pU/c/Dld8pLc1YUpUxcfOuABgdih3vFwNgmlyXEOd6JsyRVe4fkLYy3B+KdXm4Tch4=</
> ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><saml2:Su
> bject><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">_ee6f1b4caffb3
> 4e7ec9dd6196a48161c</saml2:NameID><saml2:SubjectConfirmation
> Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"><saml2:SubjectConfirmat
> ionData 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><sa
> ml2:Audience>https://sp.testshib.org/shibboleth-sp</saml2:Audience></s
> aml2:AudienceRestriction></saml2:Conditions><saml2:AuthnStatement
> AuthnInstant=
"2
> 014-11-13T14:58:33.104Z"
> SessionIndex="_53201c5ff6945bde10cf00907c3e855e"><saml2:SubjectLocalit
> y
> Address="192.168.42.42"/><saml2:AuthnContext><saml2:AuthnContextClassR
> ef>urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos</saml2:AuthnContext
> ClassRef></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/S
> AML2/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/S
> AML2/Redirect/SSO|
> 14:58:33.138 - INFO [Shibboleth-Audit:1028] -
> 20141113T145833Z|urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect|_f
> 5f27cf7d9cab13afa6b246b63f42bc2|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|_4
> b2993720c9bd10984839670e7088021|username at INTERNAL.UWIC.AC.UK|urn:oasis
> :names:tc:SAML:2.0:ac:classes:Kerberos||_ee6f1b4caffb34e7ec9dd6196a481
> 61c||
>
> 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_princi
> palname.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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list