| Messages Errororg.ietf.jgss.GSSException, major code: 13, minor code: 0 major string: Invalid credentials minor string: Cannot get credential from JAAS Subject for principal: HTTP/192.168.0.25@168.0.25 |
 |
I then decided to enable Tracing, I only had my DMGR running at this stage, but this only revealed the same error.
So I resorted to adding the host-name to the /etc/host file. For some unknown reason WAS had deiced that it could no longer speak to the DNCS server I had in my lab, so it could not resolve dmgr.test.kkdc.com which was used for the hostname in the Deployment Manager Profile, then the process worked? I think this is a bit of a bug in WAS, as yesterday it was working fine! I did notice however, that my clicks were skewed. My Linux CentOS 7 Server is loosing time. I added NTP, however I think because it is a VM there is a problem with updates coming in from the time servers? This could be a potential influence, however I ruled it out when the manually updated the dates on both y Linux and AD (Win2012) sever, the problem persisted. So I don’t really know the answer, accept that adding the hostname to the local host file resolved the issue however this defeats the purpose of DNS?
FYI: The trace settings I used on my Deployment Manager (Administration Console)
 |
Click on Change log detail levels as seen below:
 |
Change logging to include com.ibm.ws.security.spnego.*=all for example:
 |
Notice I used the run-time tab, so that tracing stays on even if I restart the DMGR process
When I tail the trace.log file I found:
| [22/09/15 20:41:55:167 BST] 000000b4 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /var/apps/was855_kerberos/profiles/SSOPOC_dmgrProf/logs/ffdc/dmgr_36deb84f_15.09.22_20.41.55.1637580100958811687413.txt com.ibm.ws.security.auth.kerberos.admintask.CreateKrbAuthMechanism.afterStepsExecuted 427 [22/09/15 20:41:55:168 BST] 000000b4 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /var/apps/was855_kerberos/profiles/SSOPOC_dmgrProf/logs/ffdc/dmgr_36deb84f_15.09.22_20.41.55.1673223078550322551753.txt com.ibm.ws.security.auth.kerberos.admintask.CreateKrbAuthMechanism.afterStepsExecuted 439 [22/09/15 20:41:55:169 BST] 000000b4 CreateKrbAuth E Validating Kerberos configuration failed [22/09/15 20:41:55:181 BST] 000000b4 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvider logIncident FFDC1003I: FFDC Incident emitted on /var/apps/was855_kerberos/profiles/SSOPOC_dmgrProf/logs/ffdc/dmgr_36deb84f_15.09.22_20.41.55.174631418603922711281.txt com.ibm.ws.security.auth.kerberos.admintask.CreateKrbAuthMechanism.afterStepsExecuted 580 |
var/apps/was855_kerberos/profiles/SSOPOC_dmgrProf/logs/ffdc/dmgr_36deb84f_15.09.22_20.41.55.1637580100958811687413.txt
Benefits of using Kerberos
When using Kerberos authentication, the user’s text password never leaves the user’s personal computer. After the user logs in to the system, the user is issued an encrypted Kerberos ticket that allows the user to gain access to other applications. After a user logs in, the user can gain access to J2EE, Web services, .NET, Web browser clients, and more without logging in a second time, using the Kerberos and the SPNEGO technology
Glossary of terms:
Below is a table of important terms used in this guide:
| Term | Description |
| Key distribution center |
A key distribution center (KDC) is an integral part of using Kerberos. Kerberos uses symmetric key cryptography and requires a trusted third party, in this case the KDC. The KDC has three logical components
|
| Authentication Server |
Handles requests from a client that wants to obtain a Kerberos ticket representing proof of identity. The authentication server first authenticates the client (for example, with a user ID and password verification). If the authentication is successful, the authentication server returns a Kerberos ticket called the ticket-granting ticket (TGT) that represents proof of identity. |
| Ticket-Granting Server |
(TGS) handles requests for a service ticket, which the client uses to access a TGT application or service. The TGS validates the client’s TGT and returns a service ticket. |
| User Registry | Holds Kerberos user information, such as the user ID, password, and the shared secret Information. (sometimes refer to as the user database) |
| Kerberos realm and principal | A Kerberos realm is often referred to as an administrative domain. A realm consists of members, which can be users, servers, services, or network resources, that are registered within a KDC database. Each of these members has a unique identifier called a Principal. The Kerberos realm is made up of the KDC and all of its principals The principal is a unique identifier to which the KDC can assign tickets. A principal name includes the following components, as shown in the following example: primary/instancename@REALM |
| Primary name | The primary name can be the user’s name, the host, or the name of the service. An example of a user principal in the TEST.KKDC.COM realm is: bobjackson@TST.KKDC.COM An example of a user principal in the KKDC.COM realm is: bobjackson@KKDC.COM An example of a machine’s (host) principal in the TEST.KKDC.COM realm is: dmgr@TEST.KKDC.COM |
| Instance name | The instance name is optional. It is used to further define the primary name, for example HTTP/dmgr@KKDC.COM Note that the principals HTTP and HTTP/dmgr are two completely separate principals with different passwords and possibly a different set of authorities. The instance name component is also used to specify a host or a service principal. In this case, it can be the fully qualified domain name of the host, such as telnet/dmgr.test.kkdc.com@KKDC.TEST.COM. |
| Realm name | The REALM name is the name of the Kerberos realm, which is usually the domain name in uppercase letters. For example, if the domain is kkdc.com then the Realm would typically be KKDC.COM, but you can define what ever is required. I recommend sticking to conventions as much as possible to be uniform with other organizations implementations and support materials. |
| Kerberos ticket |
The word ticket is used to describe how authentication data is transmitted in the Kerberos environment. Tickets are essentially an encrypted data structure that uses shared keys that are issued by the KDC to communicate in a secure fashion. The purpose of the ticket depends on where it was created. |
| Kerberos token |
A Kerberos token, referred to as the Kerberos authentication token KRBAuthnToken, is created when the client authenticates with WebSphere. If a client sends the delegate Kerberos credential as part of the authentication request, then the KRBAuthnToken includes the client delegate Kerberos credential. Otherwise, the KRBAuthnToken includes the Kerberos principal and the realm name that the client is using to authenticate. |
How Kerberos works
When a client requests an initial authentication, the authentication server authenticates the client. If the authentication is successful, the authentication server returns to the client a TGT that is used to request tickets for other services in the network. When the client wants to use a service in the network, it sends a request including its TGT to the TGS. The TGS responds by issuing and sending a service ticket. When the client uses a service in the network, it sends a request that includes its service ticket to the server that hosts the service. The server accepts the service ticket and executes the service.
|
|
This guide is one of several security guides on the topic of security This guide focuses on the configuration of Kerberos used for security purposes. |
Setting up Kerberos using Microsoft Active Directory
In this section we will cover the specific to setting up a new Microsoft Active Directory using Windows 2012 Server. We will then promote this machine to an AD Primary Domain Controller (PDC) so that we can join a test Windows workstation to the Windows Domain. We will then be able to test Single Sign On (SSO) by logging into the Windows workstation, then trying to access a secure application running in a secure WAS server. The user will not be asked to login to the Application, due to the SSO configuration.
Microsoft Kerberos KDC
Kerberos is implemented in Microsoft Windows Server 2000 and later. The implementation of Kerberos on a Windows server is composed of the Key Distribution Center (KDC) as a domain service. The KDC uses the domain’s Active Directory as its user registry. The KDC provides two services:
- Authentication service
- Ticket-granting service (TGS)
These services are started automatically and run in the domain controller for a Microsoft Active Directory architecture. When a user logs on to the Windows domain, the information that the user enters is captured by the logon program and is transmitted to the computer’s local security authority (LSA). The LSA is a Windows component that authenticates users to the local system. This LSA then communicates with the network’s KDC in order to receive ticket-granting tickets and service tickets so that the user can access Kerberized services on the Windows domain. Kerberos on Windows server platforms uses Active Directory for all information about Kerberos principals on the Kerberos network. The encryption key that is used to communicate with Kerberos principals is stored in the Active Directory database in the user’s profile. Active Directory plays the role of an LDAP server on a Windows server and is also used as the KDC database. This dual role can be a g
