Ping IWA AdapterQuick Start Configuration Notes
See the IWA IdP Integration Kit document for complete instructions
0. Geek Notes: kerberos
Kerberos is a secure method for authenticating a request for a service in a computer network. Kerberos was developed in the Athena
Project at the Massachusetts Institute of Technology (MIT). The name is taken from Greek mythology; Kerberos was a three-headed dog
that guarded the gates of Hades. Kerberos lets a user request an encrypted "ticket" from an authentication process that can then be used
to request a particular service from a server. The user's password does not have to pass through the network.
In Windows the three heads of Kerberos comprise the Key Distribution Center (KDC), the client user and the server with the desired
service to access. The KDC is installed as part of the domain controller and performs two service functions: the Authentication Service
(AS) and the Ticket-Granting Service (TGS). Three exchanges are involved when the client initially accesses a server resource:
1. AS Exchange
2. TGS Exchange
3. Client/Server (CS) Exchange
Reference http://technet.microsoft.com/en-us/library/bb742516.aspx
1. Configure the Active Directrory Ping User - for Kerberos
Create or obtain an AD user account for Ping Federate to access AD to validate authentication requests. This user should have READ
access to the entire AD and the password should not expire. For example:
2. Configure Active Directory Computer – for use with NTLM
Create or obtain a COMPUTER ACCOUNT that is used for NTLM authentication. If you will only be using Kerberos then there is no need
to do this. An example is:
3. NTLM only - Edit Computer password (Server 2008 with ADSI Edit)
You must add a password to the computrer account. Ping provides a VB script to do it but in the later versions of Windows server use bthe
ADSI tool. This shows how easy it is. (Server 2003 use the SetComputerPass.vbs provided in the kit)
4. Create (Server Principal Name) SPN for IWA Kerebros
Run the setspn command with the Ping Federate full qualified host name AND the user account creatred above for example:
Geek Note: A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. Each SPN specifies
a unique endpoint for client activity using the extended protection features for Windows authentication (in our case Kerberos). To
authenticate a service, a client application composes an SPN for the service instance to which it must connect.
C:\ setspn -a HTTP/bz-training1.corp.pingidentity.com bzaino
A successful command output looks like this:
Registering ServicePrincipalNames for CN=Bart M.
Zaino,CN=Users,DC=pstrainingad,DC=pingidentity,DC=com
HTTP/bz-training1.corp.pingidentity.com
Updated object
Testing – to validate the command
C:\ setspn -l bzaino
Registered ServicePrincipalNames for CN=Bart M. Zaino,CN=Users,DC=pstrainingad,
C=pingidentity,DC=com:
HTTP/bz-training1.corp.pingidentity.com
Note: after creating the SPN, the user must re-authenticate (log-out & back in)
5.
Install Ping Federate IWA adapter (these instructions reference the version 2.4 kit)
These instructions assume that Ping Federate has been installed!
a. Install the IWA Adapter kit by
b. Unzipping the distribution ZIP file and copy the following files to the server\default\deploy directory of the Ping
installation:
•
•
•
c.
dist\pf-iwa-authn-adapter-2.4.jar
dist\jcifs-krb5-1.3.12-PF.jar
dist\jespa-1.0.14.jar
Start or restart Ping Federate.
6. Create the IWA IDP Adapter
The screen captures below show the final result of the adapter configuration process.
IdP Adapter Screen Left Side
•
•
•
•
Domain = the domain of the AD server (it’s the domain name minus the host name from the FQDN)
Domain controller = the AD server (combining these gives the FQDN)
Kerberos User / password = The user created in step 1
NTLM User / password – the computer account from step #2 (if not using NTLM enter the Kerberos credentials again
Right Side •
•
DNS Server = the DNS server – customer must provide
IP ranges = the machines that we will authenticate
When you complete the above configuration the KDC will be contacted – if the Domain, Host & Kerberos users are correct the data is
accepted otherwise you see errors in the UI (see the log file for additional errors).
IdP adapter – Advanced Tab
Most customers leave these as default but items you may want to change are
• Challenge retires – number of bad login attempts – good for troubleshooting
• Kerberos Only – if not doing NTLM
Note – Auto Config Kerberos – this option automatically configures the krb5.conf based on the adapter configuration (FQDN and user
name) and is needed for connection. The file is located in:
<pf-install>\server\default\data\adapter-config\krb5.conf
Geek note: The krb5.conf file contains Kerberos configuration information, including the locations of KDCs and admin servers for the
Kerberos realms of interest, defaults for the current realm and for Kerberos applications, and mappings of hostnames onto Kerberos
realms. Reference: http://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5/doc/krb5-admin/krb5.conf.html
7. Create the Connector
The screen captures below show the final result of the connector configuration process.
SP connection
This was taken as copy of the default Java sample so there is nothing unique about this section
8. Browser setup
IE –
a. Under the Security tab for the Local intranet, add to the list of accessible Web sites the domain name (FQDN) that is part of
the Ping Federate URL used to start SSO (<pf-idp.domain.name>). Using the Trusted sites WILL CAUSE PROBLEMs
b. Click the Connections tab in the Internet Options dialog and select Lan Settings and ensure Use a proxy server for your LAN is
checked then click Advanced. In the Proxy Settings dialog box, enter the Ping Federate IdP server domain in the Exceptions field.
For example *.Ping Federate.com
Firefox
a. Enter about:config into the address bar.
b. On the configuration-setting page, find the following properties and set their values to the fully qualified domain name of the Ping
Federate server:
• network.negotiate-auth.trusted-uris (for Kerberos)
• network.automatic-ntlm-auth.trusted-uris (for NTLM)
9. Testing the installation
After creating the connector and adapter test the operation by logging into a windows machine that is protected with the Ping federate
solution.
I used the test applications and went to the following endpoint to start the process
https://<PF server FQDN>:9031/IdpSample
I received an HTML challenge to log in. This will start the Kerberos authentication process
The server log follows (using IE from a browser in the same domain as the AD server)
Note there is no final landing page configured
User initiates SSO to Ping Federate. Ping Federate challenges browser for service ticket.
13:29:39,096 DEBUG [org.sourceid.servlet.HttpServletRespProxy] adding lazy cookie
Cookie{PF=AOBgzVpePr9AL8bKsEiKNx; path=/; maxAge=-1; domain=null} replacing null
13:29:39,096 tid:1fd9457d0 DEBUG [org.sourceid.websso.servlet.IntegrationControllerServlet] GET: https://bztraining1.corp.pingidentity.com:9031/idp/startSSO.ping
13:29:39,096 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] adding lazy cookie
Cookie{pfidpaidtemp=IWA3; path=/; maxAge=-1; domain=null} replacing null
13:29:39,112 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] + IWAlookupAuthN
13:29:39,112 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter]
Request
doesn't end with ResumeUrl. Redirect to ResumeURL:
/idp/resumeSAML20/idp/startSSO.ping?PartnerSpId=bart:iwa&TargetResource=http://google.com&IdpAdapterId=IWA3
13:29:39,112 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] - IWAlookupAuthN
return
*** SET IDP Opentoken cookie here ****
Cookie: idpopentoken=T1RLAQLUyO04HCnzlRfKtauUfprd4hP0eRAOO6tOe3HVkKOa7ESblRDEAACge7jvmLvm5LSdwOdn2ZNAy3KzYLkeGY4aQ37eNHUadU8scxTozhbVVu3_CdVxs6rvelxD5ncCqU4EE2dxId-E4t6RIj5ToADcGBKc-u0peARFSpuM69rblY1y3_TtygQjav5DwU4Hl7AS8b_kE24iTDNxKoLDB68--AD_wI0B8fTWbBZmnPJW1cbKMfbOIhTiQNKC07a0N1x66bKuRUwA**
13:29:39,112 tid:1fd9457d0 DEBUG [org.sourceid.saml20.bindings.BindingServiceImpl] Not transporting protocol
response message because the HTTP response has been committed (this is a normal condition usually due to an
adapter or other component redirecting the user or writing its own content to the response).
Browser responds to challenge on Ping Federate resumePath.
13:29:39,112 tid:1fd9457d0 DEBUG [org.sourceid.websso.servlet.IntegrationControllerServlet]
GET: https://bz-training1.corp.pingidentity.com:9031/idp/resumeSAML20/idp/startSSO.ping
13:29:39,112 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] + IWAlookupAuthN
Browser does not have service ticket so Ping Federate requests that the browser get the ticket from the Domain Controller.
[com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter]
WWW-Authenticate header not found
13:29:39,112 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] adding lazy cookie
The browser sends a message to the Domain Controller requesting the issuance of a TGT. The request is in plain text form
(without any encryption), and includes the username of the user, but does not include their password.
Cookie{PF=AOBgzVpePr9AL8bKsEiKNxODSbjau5OuskJfJVHODDFV; path=/; maxAge=-1; domain=null} replacing null
13:29:39,112 tid:1fd9457d0 DEBUG [org.sourceid.saml20.service.impl.localmemory.InterReqStateMgmtMapImpl]
setAttr(oldKey: null, newKey: ODSbjau5OuskJfJVHODDFV, name: NUMBER_OF_ATTEMPTS, value: 1)
13:29:39,112 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] clientIP =
172.16.114.170
*** Browser gets a 401 unauthorized and starts the WWW-Authenticate: Negotiate
13:29:39,112 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter]
WWWAuthenticate: Negotiate requested from client.
13:29:39,112 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] flush cookies: adding
Cookie{PF=AOBgzVpePr9AL8bKsEiKNxODSbjau5OuskJfJVHODDFV; path=/; maxAge=-1; domain=null}
13:29:39,112 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] - IWAlookupAuthN
return
13:29:39,112 tid:1fd9457d0 DEBUG [org.sourceid.saml20.bindings.BindingServiceImpl] Not transporting protocol
response message because the HTTP response has been committed (this is a normal condition usually due to an
adapter or other component redirecting the user or writing its own content to the response).
INFO [STDOUT] btpool0-10, WRITE: TLSv1 Application Data, length = 32
The Domain Controller issues a TGT to the browser.
INFO
[STDOUT] btpool0-4, READ: TLSv1 Application Data, length = 5296
The TGT contains a session key in encrypted form. To encrypt the session key, the Domain Controller uses a key derived
from the user's password. This means that only the user (via the browser) can decrypt the TGT and fetch the session key.
Therefore, although the browser does not need to know the password to request a TGT, it does require the password to
process or use the TGT.
Authorization: Negotiate
YIIHEwYGKwYBBQUCoIIHBzCCBwOgMDAuBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKKwYBBAGCNwICHgYKKwYBBAGCNwICCqKCBs0EggbJYIIGxQYJK
oZIhvcSAQICAQBugga0MIIGsKADAgEFoQMCAQ6iBwMFACAAAACjggUuYYIFKjCCBSagAwIBBaEfGx1QU1RSQUlOSU5HQUQuUElOR0lERU5USVRZLk
NPTaI1MDOgAwIBAqEsMCobBEhUVFAbImJ6LXRyYWluaW5nMS5jb3JwLnBpbmdpZGVudGl0eS5jb22jggTFMIIEwaADAgEXoQMCAQKiggSzBIIEr6C
zhCz66XXuXwmh51Q2T6XbuJ0boQiaK9+l0IrgpShuJ2H4kX92QzLmQbydT2cC0T10WpMy4mxuv5XStU8W5V7glKuMgYBD5giz2e2aADKfZ7656Kf8
CHdtSUmcjdDp40EAlg/unjv5sS6E4DgYsb8INYZko1rKMl/A09ekibD8i/9hzvzO8ejmU1UbdE6A4p+/2no+D+JPshMrPZIN6lWas5dBFMqbyreQs
Niu/9xSNhs5XS9Y8nGsyrOwHhza8qdrH+Cxhsf01Z07d1lCLuOkTYWE/scc0W3nY5c+IAXIr+km4pOSFHjbkVm82i4rrzdkeCbyR7rhuSsilonAUc
MN01f8e7lNxycMb0I7NL0AkjpWcVc6uhwdD6HCNXaYm3XFBPNIoscqdG/HPo3j14Z3fokvsKXD0+7OoS505wiitWziVBUKB1Nq0SVKU6QnxAuTK8m
Uv3Yon03kQovhFcqba6i3gMVT01HkqSaOyGg/R9EedYxblkSZlDLzx6jP4wWL9c5hBxoR2VlYOlRkv8lVIZd2PapJAi5TF3Y+3so71e4QtVzRd5+U
aqO9pqmOZFc5pZVCMgoSrQVRnRyxK5TadLbONilN5iWpxfOK2KvxIfQD6TFDToF/edoCk20dtV00eMS+53Cs2NjQWAquatJ5ZZpiJ66r47ZeIeuVy
CzWrmz9BduhhBOZA6pfc885APX8y81YRsssXpyTRuWMtqEkLl33KMeBIEKmZHBNXKVNy7BszHdO4Pz5FM9tr+ii7CrIGnS+uCND8sV4LkLyGMSklm
xfkLCAjm9quxCLx3tOJ9JyE1M3Vvo1Vv9EAx2Gmj+R1jgl9Ws+TEfeUiw8PSAjM5zKGfYCD7ggpLjP/K4LY3MgdD6VlVBPTTWXqJZYqmqJbHT6Cba
GuBkR2CoA36lYAQPj3HWvDsBt4grCNnsyLBSnIpoo8sXlya/NHdR6A1OHmaLqgQ8fAT9vjkh8N0rWkU8qfw3qfhXFDFMzq7bZDyH2Tk7lFYKSkIG2
WtKykmf0Sq6nOVApmqy3K42XPSrtoQi1ymf4zG0fT60g/pENrTw/N1PZ1v54Q6snl1z1vBpMKAK9Tg1OzWK2irbGDqPNj2ikaeBbb+CuVsLQgr4U8
fFDSk/sDPolptDbykPpfGzioSol8TisOpXMv3DfV8SXas3jMny6u6Qjy+dbMNYt2fg2D3pJxRugUXckffVuOcOsoxQPODSyI6dI96Tfy0lI/opCDc
osyrHEJ46ohsa2g0wYFnKaOYp181HCxqaemdDAEVAiFHD3zOdqydGMc8v0xLugl3NI5IXZZVVIFi2PcVEs1icxcFAprdpj8TNwXWcktoRj+OXH8H5
ddryQ9RKy1QvFTY7vmLjBLPPvud1ogw9KZa25wLhZX3FSJ8PSFaGTq91c6xMBzzM77mrkGXXVqy1aAr82nz06+8pvmxXLkSy35Rl/WavonmGV1VP2
YbfCHbm4fCQUwWpM6AsGc9BM2abPp6Gvr0bk6Q2kh2ZOrQCTGpJbAVKYYw+tnYN8yQWLL5yipDfb8Cfz8cV6WGd8yIUjztJQUgjSTEGrXExOGTxzk
L0Ax1cChHnAOpbQpIIBZzCCAWOgAwIBF6KCAVoEggFWwFnAPz0Bhb965pid2Ce97c5s4eLLyVd9kz390NPVOqMlM925uowUmj0+NQPUju7j4+bWiH
Pu23MK8NSSQEkY65E2Mkgt7F2GIdZPBXZGOCCwc2b7zQPqS3l/HCrXzDXKasWX9Xdb6cCCOBx/VA39cee3DyoLYQwXT1Hs5NClyKyKIKrrGu4Ggib
180vMjsKPqTbpxt75t+KoIJETP3x7Nunfyiz6GGX9NcWBiA2cLd5xjlv4tgLJNmyD/+hgOfaghZZE2buXXBzw6CAnZauWsFQwejWK3hhxYoLwdyfE
l0VC/ibNGZPtAXswf8GjLy3BA3Cy/EeLmUHkbd07jzkrEPfjZW6R+BRW7dTEFshMLVh6F4R17Tq2D5EC2kB5N9rmC8k9dt28gg24F4jOUh+3LWo5K
J5BdS+JEQkENmNTb90+JGF85BeffR/4Qy4RqTpoS32cP+t1
The browser decrypts the TGT and extracts the session key from it. The browser then authors a request for a service ticket.
The browser decrypts the message received from the Domain Controller and fetches the sub-session key inside the message
as well as the service ticket.
13:29:39,127 tid:1fd9457d0 DEBUG [org.sourceid.websso.servlet.IntegrationControllerServlet] GET: https://bztraining1.corp.pingidentity.com:9031/idp/resumeSAML20/idp/startSSO.ping
13:29:39,127 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] + IWAlookupAuthN
13:29:39,127 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] Token Type =
KERBEROS
13:29:39,127 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] Negotiate
13:29:39,143 tid:1fd9457d0 INFO [STDOUT] Debug is true storeKey true useTicketCache false useKeyTab false
doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null
tryFirstPass is false useFirstPass is false storePass is false clearPass is false
13:29:39,143 tid:1fd9457d0 INFO [STDOUT] Refreshing Kerberos configuration
13:29:39,143 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.kerberos.KerbLoginHandler] Callback:
javax.security.auth.callback.NameCallback@196b220
13:29:39,143 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.kerberos.KerbLoginHandler] Callback:
javax.security.auth.callback.PasswordCallback@887276
The browser attempts SSO again to Ping Federate, this time with the service ticket. A service ticket is valid only for
communication between two parties – in this case, between the browser and Ping Federate. No one else can use the service
ticket. Therefore, while requesting the service ticket, the browser specifies the SPN of the Ping Federate server with which he
plans to use that service ticket. The server should be already registered with the Domain Controller (by running the setspn
command as outlined in the IWA Integration Kit User’s Guide).
13:29:39,143 tid:1fd9457d0 INFO [STDOUT] [Krb5LoginModule] user entered
username:[email protected]
[STDOUT] default etypes for default_tkt_enctypes:
[STDOUT] 3
[STDOUT] 23
[STDOUT] .
[STDOUT] Acquire TGT using AS Exchange
[STDOUT] default etypes for default_tkt_enctypes:
[STDOUT] 3
[STDOUT] 23
[STDOUT] .
[STDOUT] >>> KrbAsReq calling createMessage
[STDOUT] >>> KrbAsReq in createMessage
[STDOUT] >>> KrbKdcReq send: kdc=pstrainingad.pstrainingad.pingidentity.com TCP:88, timeout=9000, number
of retries =3, #bytes=174
The Domain Controller authors a service ticket for the server.
This ticket contains the browser's authentication data and a new cryptographic key, called a sub-session key. The Domain
Controller encrypts the service ticket with the secret key of the server (the secret key is a shared secret between the Domain
Controller and the server). This means that only the server can decrypt the service ticket.
The Domain Controller authors a message and wraps the service ticket inside of it.
The Domain Controller also copies the sub-session key inside the message. Notice that the sub-session key is now contained
in the message twice: once directly in the message and again inside the service ticket.
The Domain Controller encrypts the complete message with the session key from above and sends the message to the
browser.
[STDOUT] >>>DEBUG: TCPClient reading 720 bytes
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
>>> KrbKdcReq send: #bytes read=720
>>> KrbKdcReq send: #bytes read=720
>>> EType: sun.security.krb5.internal.crypto.DesCbcMd5EType
>>> KrbAsRep cons in KrbAsReq.getReply bzaino
default etypes for default_tkt_enctypes:
3
23
.
Only the browser can decrypt the message and extract the sub-session key as well as the service ticket. But the browser
cannot decrypt the service ticket -- only the server can. Therefore, no one else can use the service ticket for any purpose.
13:29:39,174 tid:1fd9457d0 INFO [STDOUT] principal is [email protected]
13:29:39,174 tid:1fd9457d0 INFO [STDOUT] EncryptionKey: keyType=3 keyBytes (hex dump)=0000: 3D B6 7C 29 76 F7 08
0B
13:29:39,174 tid:1fd9457d0 INFO [STDOUT] EncryptionKey: keyType=23 keyBytes (hex dump)=0000: BE B0 65 85 38 B4
C2 6A
CC 04 91 9D C7 06 7B EE ..e.8..j........
13:29:39,174 tid:1fd9457d0 INFO [STDOUT] Added server's keyKerberos Principal
[email protected] Version 0key EncryptionKey: keyType=3 keyBytes (hex dump)=
0000: 3D B6 7C 29 76 F7 08 0B
13:29:39,174 tid:1fd9457d0 INFO [STDOUT]
[Krb5LoginModule] added Krb5Principal
[email protected] to Subject
13:29:39,174 tid:1fd9457d0 INFO [STDOUT] Added server's keyKerberos Principal
[email protected] Version 0key EncryptionKey: keyType=23 keyBytes (hex dump)=
0000: BE B0 65 85 38 B4 C2 6A
CC 04 91 9D C7 06 7B EE ..e.8..j........
13:29:39,174 tid:1fd9457d0 INFO [STDOUT]
[Krb5LoginModule] added Krb5Principal
[email protected] to Subject
13:29:39,174 tid:1fd9457d0 INFO [STDOUT] Commit Succeeded
Ping Federate validates the Kerberos Ticket
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator] GSSManager implementation
loaded.
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator] serverNameRealm:
[email protected]
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator] GSSName
created:[email protected]
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator]
GSSContext created sucessfully.
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator]
ticket verification started
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
[STDOUT]
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes:
3
1
23
16
[STDOUT] 17
[STDOUT] 18
[STDOUT] .
[STDOUT] >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
[STDOUT] >>> Config try resetting default kdc PSTRAININGAD.PINGIDENTITY.COM
[STDOUT] object 0: 1309180480205/205444
[STDOUT] object 0: 1309180480205/205444
[STDOUT] replay cache found.
[STDOUT] >>> KrbApReq: authenticate succeed.
[STDOUT] >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
[STDOUT] >>>Delegated Creds have [email protected]
sname=krbtgt/[email protected] authtime=null
starttime=20110627131440Z endtime=20110627225507ZrenewTill=20110704125507Z
[STDOUT] Krb5Context setting peerSeqNumber to: 661641207
[STDOUT] >>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
[STDOUT] Krb5Context setting mySeqNumber to: 699910760
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator] byteArr NULL
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator] secContext established
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator]
ticket verification completed successfully.
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator]
[email protected]
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator] 1.2.840.113554.1.2.2
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator]
Ticket verified sucessfully in specified GSSContext.
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator]
userNameWithDomain retrieved succesfully.
13:29:39,174 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.KerberosValidator]
IWASubject created succesfully.
13:29:39,174 tid:1fd9457d0 INFO [com.pingidentity.adapters.iwa.idp.KerberosValidator] Current Total Memory is:
259653632
13:29:39,174 tid:1fd9457d0 INFO [com.pingidentity.adapters.iwa.idp.KerberosValidator] Current Free Memory Is:
203745560
13:29:39,174 tid:1fd9457d0 INFO [com.pingidentity.adapters.iwa.idp.KerberosValidator] Cleaning LoginContext
13:29:39,190 tid:1fd9457d0 INFO [STDOUT]
[Krb5LoginModule]: Entering logout
13:29:39,190 tid:1fd9457d0 INFO [STDOUT]
[Krb5LoginModule]: logged out Subject
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] adding lazy cookie
Cookie{PF=AOBgzVpePr9AL8bKsEiKNxiP6Vq559wYOAW0nqFkCU7I; path=/; maxAge=-1; domain=null} replacing null
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.saml20.service.impl.localmemory.InterReqStateMgmtMapImpl] Object
removeAttr(oldKey: ODSbjau5OuskJfJVHODDFV, newKey: iP6Vq559wYOAW0nqFkCU7I, name: NUMBER_OF_ATTEMPTS): 1
13:29:39,190 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter]
NUMBER_OF_ATTEMPTS removed from session
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] adding lazy cookie
Cookie{PF=AOBgzVpePr9AL8bKsEiKNxynUwpOtBef5SFRyVv5UR8L; path=/; maxAge=-1; domain=null} replacing
Cookie{PF=AOBgzVpePr9AL8bKsEiKNxiP6Vq559wYOAW0nqFkCU7I; path=/; maxAge=-1; domain=null}
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.saml20.service.impl.localmemory.InterReqStateMgmtMapImpl] Object
removeAttr(oldKey: iP6Vq559wYOAW0nqFkCU7I, newKey: ynUwpOtBef5SFRyVv5UR8L, name: domainRowIndex): null
13:29:39,190 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter]
domainRowIndex removed from session
13:29:39,190 tid:1fd9457d0 DEBUG [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] - IWAlookupAuthN
return
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] adding lazy cookie
Cookie{pfidpaid=IWA3; path=/; maxAge=31536000; domain=null} replacing null
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] adding lazy cookie
Cookie{pfidpaidtemp=; path=/; maxAge=0; domain=null} replacing null
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.saml20.domain.AttributeMapping] Source
attributes:{Domain=PSTRAININGAD.PINGIDENTITY.COM, Username=bzaino, TargetResource=http://google.com} Resulting
attributes:{SAML_SUBJECT=bzaino}
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.util.log.AttributeMap] Ignoring attempt to add null value to
attribute map for SAML_AUTHN_CTX
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.util.log.TrackingIdSupport] [cross-reference-message]
PFSessionXRefID:Uxzq7blnpzdcdCQ1DIJl8NaxmZK
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.saml20.service.impl.localmemory.IdpSessionRegistryMapImpl]
registerSessionIssued: authnbean f7dcd1dc3acabf014d9bf71ea08b6b9d93fa2ddb | assertion id
Uxzq7blnpzdcdCQ1DIJl8NaxmZK
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.saml20.service.impl.localmemory.IdpSessionRegistryMapImpl]
registerAuthnBean IdpHashableAuthnBean: f7dcd1dc3acabf014d9bf71ea08b6b9d93fa2ddb with session id
AOBgzVpePr9AL8bKsEiKNx. Session now has 1 beans associated with it.
13:29:39,190 tid:1fd9457d0 DEBUG [org.sourceid.util.log.TrackingIdSupport] [cross-reference-message]
entityid:bart:iwa subject:bzaino
13:29:39,206 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] flush cookies: adding
Cookie{pfidpaid=IWA3; path=/; maxAge=31536000; domain=null}
13:29:39,206 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] flush cookies: adding
Cookie{PF=AOBgzVpePr9AL8bKsEiKNxynUwpOtBef5SFRyVv5UR8L; path=/; maxAge=-1; domain=null}
13:29:39,206 tid:1fd9457d0 DEBUG [org.sourceid.servlet.HttpServletRespProxy] flush cookies: adding
Cookie{pfidpaidtemp=; path=/; maxAge=0; domain=null}
SAML 2.0 POST to Service Provider Assumes SAML 2.0 POST binding is being used. Process flow would vary depending
on protocol and binding used
Transported Response. OutMessageContext:XML: <Response Destination="https://bztraining1.corp.pingidentity.com:9031/sp/ACS.saml2" IssueInstant="2011-06-06T19:29:39.127Z" ID="MvkfgfXfP6nIN2qxUmFlxnN8Lh" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<saml:Issuer>bart:entityId</saml:Issuer>
<ds:Signature>
<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="#MvkfgfXfP6nIN2qx-UmFlxnN8Lh">
<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>hWtfb/rVSMnEhaL01X2AG5+FtGQ=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>rWXLz8NTLQEQod93OS0vhtpAcQl0gsTxNezr0cqI3rGBH9NycRwTrj2YjjPvARlo8xTGPgNSfweT
R7wjjanBpNO/RmqQUV8lNYr63eIn8BbxrSZ+u7JGzEDoi9yfHvpB1JrG7blxv4uqfzSWNNxUUPoE
wxS9ta4Rd2lDf2v6tHg=</ds:SignatureValue>
</ds:Signature>
<Status>
<StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</Status>
<saml:Assertion Version="2.0" IssueInstant="2011-06-06T19:29:39.190Z" ID="Uxzq7blnpzdcdCQ1DIJl8NaxmZK">
<saml:Issuer>bart:entityId</saml:Issuer>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos">bzaino</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2011-06-06T19:34:39.190Z" Recipient="https://bztraining1.corp.pingidentity.com:9031/sp/ACS.saml2"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotOnOrAfter="2011-06-06T19:34:39.190Z" NotBefore="2011-06-06T19:24:39.190Z">
<saml:AudienceRestriction>
<saml:Audience>bart:iwa</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2011-06-06T19:29:39.190Z" SessionIndex="Uxzq7blnpzdcdCQ1DIJl8NaxmZK">
<saml:AuthnContext>
<saml:AuthnContextClassRef>****HI MOM*****</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
</saml:Assertion>
</Response>
entityId: bart:iwa (SP)
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST
relayState: http://google.com
Endpoint: https://bz-training1.corp.pingidentity.com:9031/sp/ACS.saml2
SignaturePolicy: BINDING_DEFAULT
SAML response to SP – and routing to resource
13:29:39,221 INFO [org.sourceid.websso.servlet.MetadataServiceRedirectServlet] Invalid GET request:
/favicon.ico RemoteAddr:172.16.114.170
13:29:39,221 tid:1fd9457d0 DEBUG [org.sourceid.websso.servlet.ProtocolControllerServlet] ---REQUEST (POST) from
172.16.114.170: https://bz-training1.corp.pingidentity.com:9031/sp/ACS.saml2
---PARAMETERS--SAMLResponse:
PHNhbWxwOlJlc3BvbnNl….
<encrypted>
RelayState:
Kerberos / IWA Notes and Troubleshooting
NOTE: Ports 88/tcp/udp, 464/udp and 749 & 750 /tcp must be open for all users
How Windows Determines When To Use Kerberos or NTLM
In Integrated Windows Authentication (IWA), determining the protocol used is a multi-step process:
- The client (IE) and the server (PF) negotiate the protocol to be used. This is done via "WWW-Authenticate" HTTP headers in requests
and responses and will depend on the configuration of the server (e.g., is "Kerberos only" checked) and the browser (detailed in the IWA
documentation). In IWA 2.4, the PF adapter will offer NTLM or Kerberos to clients based on whether the source address of the request is
within or outside the "Intranet IP Range(s)" defined in the UI.
- If Kerberos is negotiated, success depends on the ability of the client to obtain and deliver a Kerberos service ticket and the server to
validate that ticket.
- If Kerberos is not successful, the client may be configured to fall back to NTLM. The more recent Windows releases (Vista, Windows7)
will NOT fall back by default security policy. Older versions of Windows (XP) will fall back to NTLM if Kerberos fails by default.
If a client is using NTLM when Kerberos is expected, you can diagnose the cause of issue by:
•
Reviewing the client and server configuration.
•
Examining communication between the client and server to see if and how the protocol is negotiated and credentials are
delivered. An HTTP trace tool such as ieHTTPHeaders or Fiddler will be useful for this.
•
Verifying that the client has obtained a Kerberos service ticket and that it is the correct one. The kerbtray tool will help do this (see
note on Kerberos Ticket Exchange below for information on Kerbtray)
•
Examining the log data (server.log and - with IWA 2.4 - iwa-ntlm.log) to verify that nothing is interfering with client-server
communication (what the client sends matches what the server receives) and for any specific errors related to the failure to
negotiate or complete Kerberos authentication.
Kerberos Ticket Exchange
The Kerberos ticket (TS) sent by the browser to the IDP is validated at the IDP thanks to the credentials (password) of the AD account
created for the IWA module specified during IWA configuration. No need of a network link between the IDP and the AD infrastructure. Can
you confirm that there is never a direct connection from Ping Federate IDP to the DC/KDC? At configuration, deployment or runtime (for
end-user authentication). PF with IWA doing Kerberos needs to talk to the KDC to:
•
•
Validate the service account during configuration
Retrieve or update its own "Ticket to Get Tickets" (TGT). Reference http://technet.microsoft.com/enus/library/bb742516.aspx#EDAA
Notes: To examine the tickets on a client
Load Kerbtray http://www.microsoft.com/download/en/details.aspx?id=23018 on the client machine then
1. Inspect the size of the TGT. If it is too large, the service ticket will be also and the header buffer size will have to be increased.
2. Look to see if there is a Service Ticket for the SPN. If there is not, then the problem is with reverse DNS.
DNS access will be necessary to do the SRV lookup if a specific KDC is not specified.
If NTLM authentication is used additional DNS lookups are done and communication with (at least one of) the DCs returned by the SRV
lookup is required.
How to Check Encryption Types in Kerberos on AD /KDC
If you have this error:
ERROR in event log KDC_ERR_ETYPE_NOTSUPP
Run gpedit.msc
Expand “Local Computer Policy” > “Computer Configuration” > “Windows Settings” >
“Security Settings” > “Local Policies” > “Security Options”
Select: “Network security: Configure encryption types allowed for Kerberos”
Select “DES_CBC_MDC” and “RC4_HMAC_MD5”
Press “OK”
File menu
Exit
Kerberos Additional Debugging (Tracing) on Windows
The registry entries that are listed in this section must be added to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Note If the Parameters key is not listed under Kerberos, you must create the key.
Entry: LogLevel
Type: REG_DWORD
Default Value: 0
This value indicates whether events are logged in the system event log. If this value is set to any non-zero value, all Kerberos-related
events are logged in the system event log.
Debugging (Tracing) the KDC Output on Windows
The registry entries that are listed in this section must be added to the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc
Note If the Kdc key is not listed under Services, you must create the key.
Entry: KdcExtraLogLevel Type: REG_DWORD Default Value: 2 Possible values:
• 1 (decimal) or 0x1 (hexadecimal): Audit SPN unknown errors.
• 2 (decimal) or 0x2 (hexadecimal): Log PKINIT errors. (PKINIT is an Internet Engineering Task Force (IETF)
•
Internet draft for "Public Key Cryptography for Initial Authentication in Kerberos.")
• 4 (decimal) or 0x4 (hexadecimal): Log all KDC errors.
• 8 (decimal) or 0x8 (hexadecimal): Log KDC warning event 25 in the system log when user asking for
•
S4U2Self ticket does not have sufficient access to target user.
• 16 (decimal) or 0x10 (hexadecimal): Log audit events on encryption type (ETYPE) and bad options errors.
This value indicates what information the KDC will write to event logs and to audits.
Entry: KdcDebugLevel Type: REG_DWORD Default Value: 1 for checked build, 0 for free build This value indicates whether debug
logging is on (1) or off (0). If the value is set to 0x10000000 (hexadecimal) or 268435456 (decimal), specific file or line information will be
returned in the edata field of KERB_ERRORS as PKERB_EXT_ERROR errors during a KDC processing failure.
If not on 2008 must restart!
Additional log4j Debug information for IWA Transactions on PingIdentity
1. Backup Ping Federate/server/default/conf/log4j.xml
2. Open Ping Federate/server/default/conf/log4j.xml in a text editor
3. Change or add the following items
<!-- ADD the following 3 items FOR EVEN MORE OUTPUT -->
<category name="com.pingidentity">
<priority value="DEBUG"/>
</category>
<logger name="org.sourceid.saml20.bindings.BindingLogProxy" additivity="false">
<level value="INFO" />
<appender-ref ref="SamlTransaction"/>
</logger>
<category name="com.pingidentity.adapters.iwa.kerberos.KerbLoginHandler">
<priority value="DEBUG"/>
</category>
* Steps to enable additional logging for Full HEAD
<category name="org.mortbay.log">
<priority value="DEBUG"/>
</category>
Additional Java Debugging Options for IWA
To enable additional JAVA debugging for Kerberos, SSl/TLS connections add the following commands to the JAVA_OPTS in the
run..bat or run.sh file
-Djavax.net.debug=ssl – for even more output use -Djavax.net.debug=all
-Dsun.security.krb5.debug=true
Similar to other underlying technology we use, you can override the default JCIFS logging by manually setting a System variable
(jcifs.util.loglevel) in the run.bat or run.properties file. The log level can then be set by adding something like ‘
"java -Djcifs.util.loglevel=3 <PF app>"
This JCIFS page outlines the various other "tweaks" that can be set - http://jcifs.samba.org/src/docs/api/overview-summary.html#scp
Using Proxies and Kerberos If this is NOT done you will NOT get a service ticket from the KDC.
The critical steps in getting Kerberos to work through the proxy are:
•
•
Define an SPN for the hostname of the proxy (i.e. "HTTP/login.myproxy.coolcorp.com and associate it with the
PF service account user (using setspn - make sure that there are no conflicting assignments for that SPN in AD.
There must be a reverse-DNS entry (PTR record) for the proxy hostname available to the browser. PTR records resolve IP
addresses into hostnames.
A PTR record (sometimes called a "host PTR record") is what lets someone do a "reverse" DNS lookup that is, they have your IP address
and want to know what your host/domain is. To do a reverse lookup in:
Unix/Linux : "dig -x" t
Windows:
C:\>nslookup
To create a PTR in windows see http://www.ucertify.com/article/how-to-create-a-ptr-record.html
How to tell it worked?
The key differentiator is that just before the SAML Response is generated you will see some PingFederate server.log records mention
Kerberos and do not mention NTLM.
From the browser header viewpoint,
IWA will send a 401 with www-Authenticate:Negotiate and www-Authenticate:NTLM, and the browser will respond with either
Authorization:NTLM and a string, followed in the next HTTP exchange with Authorization:NTLM and a much longer string (NTLM)
or the browser will respond with Authorization:Negotiate followed by a very long (1K-8K characters) string. (Kerberos)
The length of the string will be roughly proportional to the number of AD groups the user belongs to. If it gets above about 7K, you will
have to make some configuration changes to PF to allow it to accept larger HTTP header blocks.
There will be no additional 401 responses and no additional Authorization headers sent by the browser.
If you see the browser send a Negotiate string and PF responds with another 401, then Kerberos authentication has failed and the details
should be in server.log. Depending on the browser and the OS at the user side, there may or may not be a fallback to NTLM.
Once you see a Negotiate header sent by the browser you know that the reverse DNS lookup succeeded and the KDC found a setspn
user corresponding the SPN. You should then see a service ticket for that SPN in Kerbtray on the user machine. (Install from Windows
resource kit if you don't have it already.)
How the Brower Finds the SPN
All current browsers (and IE after version 6) take the following steps to determine the SPN associated with a resource:
1. Look at the IP address, which resulted from resolving the DNS hostname in the URL. In the second case, this step will be skipped.
2. Take that IP address and do a reverse DNS lookup (finding a PTR record, not an A or C record) to get a hostname.
3. Prepend that hostname with "HTTP/".
That is the SPN, which will be submitted to the KDC and for which there must be one and only one setspn account in AD.
•
•
If your internal DNS does not provide a reverse lookup (PTR record) for the AD Server then Kerberos will not be
possible and the browser will skip it and go directly to NTLM.
If your internal DNS does provide a reverse lookup, but the corresponding SPN has not been associated with an AD
account, the KDC will not return a ticket.
Distinguishing between the two cases will require looking at the Windows Event Log on the KDC involved.
If the SPN can be generated and an AD account exists, but it is not the one specified as a Kerberos service account for the
IWA Adapter, then there will be an error in Ping Federate server.log relating to verifying the Kerberos ticket.
Troubleshooting Kerberos Authentication Errors
Kerberos is the primary authentication mechanism used in Active Directory. You should do the following:
•
Verify that you can do an nslookup on the FQDN of the computer.
•
Verify that the NIC setting for the DNS has the correct domain that is listed in the DNS suffix for the connection.
•
Verify that WINS has no duplicate records that may point to other IP addresses or may point to other domains for the computer.
•
Verify that the DNS does not have duplicate records for the computer.
•
Verify the host record of the computer is in the correct domain.
•
Verify that Active Directory has no duplicate listing for the computer.
•
Verify that the account that is used for ASP has access to the SQL Server and the RAM_db database.
Common Kerberos Errors with Ping (IWA)
Also Reference: http://technet.microsoft.com/en-us/library/cc787313(WS.10).aspx
http://technet.microsoft.com/en-us/library/cc728430(v=ws.10).aspx
1. No Kerberos ticket being sent:
Also reference https://wiki.pingidentity.com/GCS/index.php/Why_am_I_not_getting_a_Kerberos_ticket%3F
a. Ping Federate is running on the same machine as the domain controller
b. The user is logged in “outside of the domain”
c.
In order to get a Kerberos ticket, the user must initiate a login within the domain. By authenticating to the domain controller, they
get a ticket. If they didn’t talk to the domain controller at all before starting the SSO, they won’t have a ticket to send when the
adapter asks for it.
d. Duplicate Service Principal Names (SPNs)
To query for multiple SPN records run: setspn -Q HTTP/<servername>
e. SPNs need to be unique. If multiple SPNs are configured for PingFederate’s base URL, a ticket will never be sent.
f.
Ping Federate has the same Base URL as the FQDN of the server it runs
g. This will fail because of duplicate SPNs
h. Incorrect Browser Configuration (see step #8 in the installation of this document)
i.
If the browser isn’t configured to send these credentials, then they clearly won’t be sent. (IWA enabled in IE) The Ping server must
also be in the intranet zone hosts in the IE browser and set up in Firefox use network.negotiate-auth.trusted-uris (for Kerberos)
j.
“Old” Windows Login for SPN user
k.
After setting the SPN, users wishing to SSO will need to re-authenticate to the domain controller. By providing credentials against,
they will get a new ticket, one that has the SPN changes. Another way of saying this: the SPN changes won’t “take effect” until
users re-authenticates.
l.
The XP credential cache bug. There is a known bug in some versions of XP that prevented the client from renewing tickets,
causing the client to fall back to NTLM.
2. GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)
A known issue causes this error with Kerberos authentication in the Sun JDK. It can be addressed by upgrading the JDK used by your
Ping Federate server instances to version 6.0 update 17 or higher.
3. jcifs.smb.SmbAuthException: Invalid access to memory location. (Using NTLM Authentication)
For an NTLM transaction to succeed, the entire client/server interchange must be with the same Active Directory server. This error
would indicate that there are possibly more than one AD servers in your environment, and the client NTLM response was relayed to an AD
server differing from the one issuing the original NTLM challenge. The only workaround at present is to limit the environment to a single
AD server. This error is presently under investigation by Engineering.
4. GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
The SPN is not set for the hostname that the client is using in the request
5. IWAisUserValid: Kerberos Exception: com.pingidentity.adapters.iwa.kerberos.KerberosException:
GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
Thus the IWA kit failed because the Kerberos ticket was for a short name (from in the hosts file) instead of the FQDN. Removing this entry
from the host file fixed the problem.
6. "LoginException: javax.security.auth.login.LoginException: Cannot get kdc for realm Yourcompany.com"
Ping Federate is unable connect to the specified domain Check that the krb5.conf is correct
7. Unexpected Runtime Authn Adapter Integration Error
This is a generic error is thrown whenever there is a problem with the specific adapter being invoked. The cause of the error will reside in
the Ping Federate server log;
8. ERROR [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] TgsValidationProblem: Could not validate Kerberos
TGT,
please make sure the service principal name is set correctly and the credential cache on client machine is refreshed by re-login
to the windows domain.
ERROR [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] Kerberos Authentication Failed
Possibly because of Extended Protection for Authentication update
BUG - see https://www.pingidentity.com/support-and-downloads/XP_KB968389.cfm
9. [com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] - IWAisUserValid: Kerberos Exception:
com.pingidentity.adapters.iwa.kerberos.KerberosException: GSSException: Failure unspecified at GSS-API level (Mechanism
level: Checksum failed)
[com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] - IWAlookupAuthN: AuthnAdapterException or Ticket denied by
DC.org.sourceid.saml20.adapter.AuthnAdapterException: TgsValidationProblem
Incorrect user password on PF IWA account used to validate the Kerberos ticket.
10 INFO [STDOUT] [Krb5LoginModule] authentication failed
Client not found in Kerberos database (6)
DEBUG com.pingidentity.adapters.iwa.idp.IWAAuthenticationAdapter] Exception: Client not found in Kerberos database (6)
The admin user authentication failed for NTLM due to the fact it was not an AD "Computer" account.
11. INFO [STDOUT] [Krb5LoginModule] authentication failed Clock skew too great (37)'.
This message indicates a lack of synchronization between the system clock on the PF server and the KDC. Time synchronization is critical
for Kerberos authentication. Correcting clock synchronization resolved the issue
12. GSSException: Failure unspecified at GSS-API level (Mechanism level:
Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)
This appears to be due to a mismatch between the encryption algorithm used to encrypt the Service Ticket and the algorithms supported
in the current release of IWA.
It may be possible to address this issue by modifying the settings of the service account used by Ping Federate to connect to the Domain
Controller. To do this, find the service user in Active Directory. Under the Account tab, check "Use des encryption types for this
account" and save.
Restart Ping Federate and verify that the IWA adapter has successfully initialized - either by reviewing the settings in the GUI or checking
server.log.
You'll need to clear any old Kerberos service tickets from clients before re-testing.
13. WARN [org.mortbay.log] handle failed java.io.IOException: FULL head
To resolve 'Full HEAD' errors, the header buffer size must be increased. The Jetty parameter that sets the default size (which is 4K) for
the header buffer is headerBufferSize. Within Ping Federate, this can set within the server/default/deploy/jetty.sar/META-INF/jbossservice.xml file is modified by changing the element "<Set name="headerBufferSize">8192</Set>" to each addConnector
element.
14. UNKNOWN_SERVER: authtime 1046294981,<user>@<company.com> for krbtgt/BOGUS.COM @Company.com, Server not
found in Kerberos database
This points to a realm mismatch most likely a configuration error. The solution to a DNS-to-realm mismatch is to ensure that all clients
have the correct mappings in place. In this rather contrived example, the default behavior of Kerberos is sufficient, since all machines in
the DNS domain wedgie.org belong to the WEDGIE.ORG Kerberos realm. However, other organizations may have a realm name different
from their DNS domain name, and it is this situation that requires special care.
This can also be caused by the server resolving to the loopback address (127.0.0.1) in the hosts file or placing the SHORT host name
before the FQDN in the hosts file
15. Hostname cannot be canonicalized while verifying initial ticket
This is caused when the application attempts to find its service principal name by performing a reverse lookup on the interface IP address
that this request was received on. If that IP address does not resolve to a hostname, this message or the earlier “cannot find service
principal” message will be generated.
16. Preauthentication failed while getting initial credentials
a. If your realm requires pre-authentication (the default in windows) then this message is Kerberos-speak for “incorrect password”
b. The KDC could not find an appropriate encryption key with which to encrypt the response. When a Kerberos 5 client contacts a
KDC through the AS exchange for an initial Ticket Granting Ticket, the client sends a list of encryption types that it understands. If
the KDC cannot find a secret key associated with one of the encryption types included in the request, it will return an error.
c. Hostname/DNS misconfiguration, or a missing
d. Incorrect Kerberos configuration file.
e. A clock synchronization problem
17. IE prompts for password on each access
Internet Explorer security settings must be configured to enable Integrated Windows authentication (IWA). By default, IWA is not
enabled in Internet Explorer 6. To enable the browser to respond to a negotiate challenge and perform Kerberos authentication, select the
Enable Integrated Windows Authentication check box in the Security section of the Advanced tab of the Internet Options menu, and then
restart the browser. Alternatively this may be an issue with the site not being in the intranet zone. IE won't send authentication details
automatically to sites that aren't located within the intranet zone.
18. KRB5KRB_AP_ERR_MODIFIED Error in Event Viewer
Basically this is stating that the Account that is running the service could not decrypt the Kerberos ticket that the KDC gave to the client.
This can happen for several reasons, but the most common are:
•
•
•
There is an account with the same SPN within the forest (Keep in mind in a multi-domain forest you need to search all domains to
include other domain trees in the forest). The KDC will give an error back of KRB_S_PRINCIPAL_UNKNOWN, but there are
instances where it will give a Kerberos ticket that the service cannot decrypt and thus get a KRB5KRB_AP_ERR_MODIFIED.
The Service Principal Name is on the wrong Active Directory account (Computer or User).
The Active Directory account that is running the service has updated / changed its password and you are experiencing the
problem because of an Active Directory Replication Latency or Active Directory Replication problem.
19. javax.security.auth.login.LoginException: Could not load configuration file <krb5.conf> (No such file or directory)
Verify that the Kerberos configuration file krb5.conf is available in the <ping install>/pingfederate/server/
default/data/adapter-config directory and is readable.
20. javax.security.auth.login.LoginException: java.net.SocketTimeoutException: Receive timed out
Verify that the Kerberos KDC is up and running.
21. javax.security.auth.login.LoginException: KrbException: KDC has no support for encryption type (14) - KDC has no support
for encryption type
Cause 1: The KDC does not support the encryption type requested. (Typically, the encryption type is specified in the krb5.conf Kerberos
configuration file.) Select an encryption type that is supported by the KDC you are using. The encryption types supported by the Kerberos
implementation from Sun Microsystems are DES_CBC_MD5,DES_CBC_CRC,and DES_CBC_MD4.
Applications can select the desired encryption type by specifying tags in the krb5.conf:
[libdefaults]
default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
If not specified, the default value is:
des-cbc-md5 des-cbc-crc des3-cbc-sha1
Cause 2: This exception is thrown when using native ticket cache on some Windows platforms. Microsoft has added a new feature in
which they no longer export the session keys for Ticket-Granting Tickets (TGTs). As a result, the native TGT obtained on Windows has an
"empty" session key and null EType. The effected platforms include: Windows Server 2003, Windows 2000 Server Service Pack 4 (SP4)
and Windows XP SP2.
Update the Windows registry to disable this new feature. The registry key allowtgtsessionkey should be added--and set correctly--to
allow session keys to be sent in the Kerberos Ticket-Granting Ticket.
On the Windows Server 2003 and Windows 2000 SP4, here is the required registry setting:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type:
REG_DWORD Value: 0x01 ( default is 0 )
By default, the value is 0; setting it to "0x01" allows a session key to be included in the TGT.
Here is the location of the registry setting on Windows XP SP2:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\
Value Name: allowtgtsessionkey
Value Type:
REG_DWORD Value: 0x01
22. KDC reply did not match expectations
The KDC sent a response that cannot be understood by the client. Verify that you have set correctly all the krb5.conf file configuration
parameters and consult your KDC vendor's guide.
23. Javax.security.auth.login.LoginException: KrbException:: Pre-authentication information was invalid (24) - Preauthentication
failed
Cause 1: The password entered is incorrect.
Cause 2: The user account does not require preauthentication – verify the properties for the user in AD.
Cause 3: Clock skew - If the time on the KDC and on the client differ significantly (typically 5 minutes), this error can be returned.