I am new to Kerberos and I am not sure how browser knows which KDC to contact for ticket for a HTTP service?
For example, I have an application (SPNEGO) running on www.xyz.example.com and my realm is example.com ( I have a linux server as KDC server), what will be the SPN created and how will browser contact KDC?
how browser knows which KDC to contact for ticket for a HTTP service?
The browser never directly contacts the KDC. Instead, it relies on the ticket cache maintained by the operating system. If the ticket for the specified service is not found in cache, then OS connects with the KDC and puts the new ticket in cache, from where the browser can pick it up.
what will be the SPN created and how will browser contact KDC?
General format of the SPN is <service class>/<host>:<port>/<service name>. If you have a web application running on xyz.example.com, then usually (not necessarily) the format of your SPN will be HTTP/xyz.example.com
SPNs are not defined automatically. Administrator has to register the SPNs at the time the keytab is generated.
Related
I am new to the xmpp server and still learning. I have chosen ejabberd server for my chat application. I have started the server but can't able to access the web admin interface. as you can see the ejabberd#localhost is already running. configuration
I started the server and it was supposed to show web admin interface but unfortunately it is not showing. I don't know what am i doing wrong.
With that configuration, the webadmin page is in
http://localhost:5280/admin/
When the browser asks login credentials, provide the JID of some account in ejabberd with admin rights (it may be vinayak#localhost or something like that) and its password.
This means that you should have already registered an account in ejabberd, and grant it admin rights in ejabberd.yml configuration file, see https://docs.ejabberd.im/admin/installation/#administration-account
We have a web application written using Liferay 6.2 and deployed on tomcat server. Application is accessed using Integrated Windows Authentication. Everything works fine if hostname is directly used to in url to access.
To hide the actual hostname, a CNAME record was created. When that is used to access, users get repeated prompts for credentials and authentication is rejected despite entering correct credentials.
We tried creating SPN for CNAME using the command setspn -a "HTTP/<<friendly name>>". Since connection is made on standard port 443 using HTTPS, no port number was specified when creating SPN. However, repeated authentication prompts still continue to appear. The application runs using a service account. Including the service account when creating SPN could be an option. Please share if there are any suggestions on what else could be tried.
What does "everything works fine" mean? Are you getting prompted and when you enter creds it works correctly, or it does SSO and logs you in without a prompt?
The fact that you're getting prompted is because a) the new cname isn't considered to be in the intranet/trusted internet zone. See Internet Options > Security > Local Intranet/Trusted Sites > Sites. Or b) the requested ticket sent to the server failed.
Also usually you don't register the cname as an SPN. You register the A record the cname is pointing to as the SPN. My guess is this is causing the failure. The SPN is getting registered to the wrong service account so the KDC is using the wrong service account key.
I'm playing around with Kerberos SSO. As experimented so far,
When I open a web app that is configured with Kerberos, from the browser, it prompts me for the username and credential, once I enter, I'm logged into the web app .
When I do a kinit from the terminal and give my credentials, I'm signed into the KDC for the given user. After kinit, when I open a web app I'm signed into the web app, without any credentials.
One possible explanation is, when I do a kinit, the TGT is stored in the OS which is available for other clients in the host machine so that my browser was able to use that TGT without prompting me for password.
Now my questions are,
Will I be able to cache the TGT without using kinit?
If yes, how can I do it using a Java client?
If the answer for the first question is yes, will I be able to do it from my web app opened in the browser?
Whenever kinit is executed, a TGT is requested and stored in OS ticket cache.
This TGT can be used to get TGS (service ticket) for multiple services.
If you haven't added your app url as a 'trusted intranet site' in browser, then browser will give you pop-up for the first time for every new session.
Browser accepts the credentials, gets the TGT from your KDC, and puts it in cache. Furthermore, using this TGT, it ask the KDC for the TGS to your app url (usually identified as "HTTP(S)/APP_SERVER_HOSTNAME").
You can verify this-
Perform klist purge to clean all the tickets from cache.
Open browser and hit your app url.
Provide credentials in pop-up and submit.
Execute klist- observe there are two tickets in cache.
One of the ticket is TGT, which spn like - krbtgt#XXX.domain.
The other is TGS for your service - usually "HTTP(S)/APP_SERVER_HOSTNAME".
Please note:
TGT is created by default when you login to the OS. So you can see there's a TGT for your user in OS cache.
OS ticket cache behavior can be platform specific (not verified by me).
You can obtain TGT/TGS or even delegate the credentials using (java)code.
Cache mentioned in your KRB conf is not necessarily the OS ticket cache.
For credential delegation, check out this - Java SPNEGO Authentication & Kerberos Constrained Delegation (KCD) to backend service
I am trying to configured SAML SSO with OpenAM as SP and PingFederate as IDP with SP-Initiated SSO and using Redirect-Post binding. I am using kerberos adapter for implementing SSO.
I have configured Kerberos adapter to use "e-glue.com" domain and provided KDC details in the configuration. I have also added "setspn" of Pingfederate server in domain controller properly.
However when I login to a computer with valid "e-glue.com" user and hit SSO url with "https://hostname.e-glue.com:1912/openam/saml2/jsp/spSSOInit.jsp?idpEntityID=ent-026330&metaAlias=/sp" it redirects me to IDP and SSO is successful and user gets created in openam.
But if I do the same thing with other domain.. which is not "e-glue.com", it still autheticates the user and user is created in openam.
This is so strange, there is something missing as the user which is not part of e-glue domain though we configured kerberos adapter to use e-glue.com KDC, is getting authenticated. I am missing something, not sure what.
Please share if you have any information about what is going wrong.
It happened because of inter-domain trust relationship.
PingFederate (IDP) is configured to authenticate users via "e-glue.com" domain.
So I logged in to my computer which was in domain "someother.domain".
But this "someother.domain" implemented an Active Directory directory service forest and has trust relationship between "e-glue.com" and itself. So all users logged in to IDP are also VALID users because of trust relationship.
It took me some time to understand this.
We have a client/server based application that is developed internally. Clients and server communicate over a TCP/IP connection with an application-specific protocol. The clients run on Windows and the server runs on Linux. All machines are in the same Active Directory/Kerberos domain/realm.
Currently, the user enters a username and password when they start the application. The server checks the username and password (authentication). Based on the username, the server also determines access to resources (authorization).
We want to add Single Sign-On (SSO) capabilities to the application. That is, we do not want the user to enter a username and password but we want to automatically logon as the current Windows user.
Of course, determining the current Windows user has to be done securely.
I have come up with the following setup:
I use SSPI (Negotiate) on Windows and GSSAPI on Linux.
When the client connects to the server, it uses AcquireCredentialsHandle (Negotiate) to get the credentials of the current Windows user.
The client uses InitializeSecurityContext (Negotiate) to generate a token based on these credentials.
The client sends the token to the server.
The server uses gss_acquire_cred() to get the credentials of the service. These are stored in a .keytab file.
The server receives the token from the client.
The server uses gss_accept_sec_context() to process the token. This call also returns the "source name", that is the current Windows user of the client.
The server uses the "source name" as the username: the server performs no additional authentication. The server still performs authorization.
This works but I do have some questions:
Is this secure? It should not be possible for the client to specify any other username than the Windows user of the client process. If a user has the credentials to create a process as another user (either legally or illegally) than this is allowed.
Should I perform additional checks to verify the username?
Are there alternative ways to achieve SSO in this setup? What are their pros and cons?
What you've described here is the correct way to authenticate the user. You should not have to worry about the user specifying a different name; that's what Kerberos takes care of for you.
If the client is able to obtain a service ticket, then they must have been able to authenticate against the KDC (Active Directory). The KDC creates a service ticket that includes the user's name, and encrypts it with the service's secret key.
The client would not be able to create a ticket for the server with a fake name, because it doesn't have the necessary key to encrypt the ticket.
Of course, this all assumes that you've set everything up correctly; the client should not have access to the service's keytab file for example, and the service should not have any principals in its key tab except its own.
There's a pretty detailed explanation of how it works here.