I would like to perform windows domain authentication using kerberos (AS request) but all I have is a cardID provided by client. I do have username but no password.
How to validate the card user as kerberos needs username and password.
Any mechanisms to validate card ID using kerberos mechanism on windows 2012/2016 server ?
Related
Hey :) I’m learning about Kerberos. I first read about the MIT Kerberos and then about the uses in Microsoft. I found some difference. I just want to be sure. Is it right that in the original MIT Kerberos a hash of the password never send from the client to the server, but in Microsoft Kerberos it happened?
Huh?
Kerberos is Kerberos. It's a well defined specification and all the different implementations are more or less implemented the same. The Windows implementation certainly has it's share of quirks, but it doesn't in any way send the password hash to the server.
Kerberos uses a key agreement process to exchange messages. Both the client and KDC know the users "long term credential" which is their password hashed using a specific key derivation function. When the client wants to send a message to the KDC, it encrypts it using the long term credential. The KDC knows that credential so it can decrypt it. The response is encrypted in the same way.
Neither party sends the password or its hash to the other in general use.
There are two separate but specific scenarios where this doesn't apply however.
When using a certificate to logon via PKINIT, Windows will include the long term credential in the user PAC of the ticket (so the workstation can decrypt it), encrypted to the Diffie-Hellman derived secret.
The other scenario is when doing FIDO logon, the long term credential is included in an authorization data element.
Both of these scenarios exist to allow clients to support legacy protocols that only understand password authentication.
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.
I have a client application (windows) which the user is logged into. From this application, the user will want to access a remote website using single sign-on (SAML) and will be authenticated by Microsoft WIF. To do this the user, will click a button which opens a local web browser, generates a SAML token (containing username and roles, etc) and makes a HTTP POST to a remote website to access it, signing them in.
I want the user to be signed-in automatically, based on their credentials from the windows application.
I know roughly how to generate the SAML token, but presume this requires the signing certificate to be installed on the local PC, which would need to be installed into all PCs in my Company.
Installing this certificate doesn't seem quite right. How else can I safely allow users to generate a SAML token which will be accepted by the Service Provider (via single sign-on)?
UPDATE:
The user is not authenticated into the Windows Application using Windows Authentication (Kerberos), we make a custom SQL call to a database of username/password.
In the win app, we will know the username and their roles, so could generate claims from this, or pass it to a remote STS to generate and sign the SAML token. But again passing this data across to the STS seems totally wrong again.
The signing certificate must not be on the user desktop. Otherwise, any user could potentially generate a SAML token with the userid it wants.
What you want is a Secure Token Service (STS): an identity provider that will authenticate your user through Kerberos (as you want to re-use the identity of the logged-on user) and give you a signed SAML token.
All of this could be done when you open a web view in your application. The starting url should be the Identity Provider endpoint for IDP-initiated SSO, with a url parameter identifying the service you want to access.
I'm trying to connect to gmail using a simple java program (like this one). But my question is:
Is there a way to do this with encrypted password and not the real password, for security reasons of course!! something like how we do in java-Oracle db ?
By default, the only authentication mechanism for IMAP is the LOGIN command, which takes an unencrypted username and password. You can add an encryption layer on top of it, either by connecting via IMAPs or starting a TLS layer via the STARTTLS command, but it still requires the client to know the cleartext password.
A server can optionally also provide SASL authentication methods invokable via the AUTHENTICATE command. The server advertises which SASL mechanisms it supports in its response to the CAPABILITY command. For instance, if the server includes the capability "AUTH=PLAIN", the client can use the PLAIN SASL authentication method via the AUTHENTICATE PLAIN IMAP command.
Gmail supports only one SASL authentication mechanism, XOAUTH:
C: 1 capability
S: * CAPABILITY IMAP4rev1 UNSELECT IDLE NAMESPACE QUOTA XLIST CHILDREN XYZZY
SASL-IR AUTH=XOAUTH
S: 1 OK Thats all she wrote! dv32if2169247ibb.17
XOAUTH is a nonstandard SASL authentication mechanism using OAuth. (The leading 'X' means it's not standardized.) Google has published a document defining the XOAUTH SASL mechanism. They've also provided a google-mail-xoauth-tools package, which includes sample code showing how to use JavaMail with Gmail via XOAUTH.
I am trying to connect a server to a XMPP server, using the MD5 Digest SASL handshake. But the XMPP server always rejects my response to the challenge. The RFC says the response should look like:
username="example.org",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
But the value of response (which I have correctly generated based on the inputs) relies on the username and password. For server-to-server communication, which username and password should it be using? The example.org username in the spec doesnt seem right..
You've probably solved this by now, but this is for the record. See RFC3920, section 6.1, item 6: "If provision of a 'simple username' is supported by the selected SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms), during authentication the initiating entity SHOULD provide as the simple username its sending domain (IP address or fully qualified domain name as contained in a domain identifier) in the case of server-to-server communications or its registered account name (user or node name as contained in an XMPP node identifier) in the case of client-to-server communications."
At least, that conditionally takes care of the username. The password I couldn't even guess at. I'm writing a client-to-server script, so I'll be using my own gmail username and password, but that isn't likely to work for server-to-server.