I am trying to understand better how Kerberos is integrated in Active Directory but I couldn't find a clear answer to this question from the Microsoft documentation.
I understand the process of getting a service ticket to a service from the KDC: client presents his TGT to the KDC along with a request to a specific service, the KDC will send back a service ticket to the client and the client uses this service ticket when accessing the service.
My question is: can I configure the KDC (Active Directory) to refuse to grant a service ticket to specific services for specific users/groups ?
I've tried to search the web for this and play around with configurations in order to achieve this, but I am beginning to suspect that the service ticket only role is to tell the service that "this user is indeed from the legitimate domain" and therefore a service ticket can be given to anyone on the domain. So for example in the case of CIFS (file server) even if I remove all shares from a computer, I can still see that every user can see this computer (i.e via \computer) and by running "klist tickets" I also see that they are granted a ticket to the CIFS service for "computer" even when they can't see any shared folder or drive on it. So specifically in this example, can I somehow make it so that a specific user will never be given a "CIFS" type service ticket for this computer ?
Not with Kerberos. It has been designed for authentication only. You wan't authorization. This is a different problem area.
This is non-trivial to setup but with Windows Server 2012 R2 AD, this is possible to do. Take a look at Authentication Policies & Siloes - http://technet.microsoft.com/en-us/library/dn486813.aspx
Related
I am having an workstation specific Kerberos issue and hope anyone here would have additional recommendation.
Our application has an application server and web server and we have kerberos configured on both application layer and web layer.
And for certain users, when we provide the Kerberos link and they are not able to authorize in. And we found out the issue is workstation specific. And on the same problematic workstation, the user could access application server via Kerberos authentication.
And on the web logic we see the following error:
[SpnegoFilter.doFilter] Although user authentication to xxx was successful, Integrated Authentication could not extract the user's credentials because it appears delegation was either not configured or disallowed
I am looking for any of Windows setting could potential lead to this issue? We check that our domain is trusted on both working and nonworking machines on the browser level and GPO settings are the same.
What you're describing is unconstrained delegation, which is the act of a user handing the remote server their TGT so the server can impersonate the user without restriction.
Windows deems this as incredibly dangerous (it is) and is moving towards disabling it outright when certain security services are enabled on the client. Specifically Credential Guard. It will also block it for users that are members of the Protected Users security group, though the fact that it's affecting specific workstations leans towards Credential Guard.
If it is the above issues the correct solution is to switch to constrained delegation.
We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
I am trying to kerberize my RESTful backend and I am not seeing anywhere in the GSS-API documentation how could I add a user/service - i.e., I understand the authentication process with GSS-API, but not the signup process. To make my question simpler : kinit is the command line tool used to add principals, is there an equivalent for GSS-API ? If the answer is no - should I go and look at the kinit source code and port it to my project (using system("kinit ...") raises security questions/problems so I am not thinking about using it) ?
Users should be added to the Kerberos database using API provided by Kerberos Distribution Centre. In Microsoft Active Directory, KDC uses LDAP as its database, so users can be added/removed using JNDI, as described here: http://cyberlizard.livejournal.com/120080.html.
kinit not a tool for adding users but for (simply speaking) "logging in", or (technically speaking) it's a tool that "obtains and caches an initial ticket-granting ticket for principal" (see: http://web.mit.edu/kerberos/krb5-devel/doc/user/user_commands/kinit.html), i.e. it takes credentials (i.e. for example principal and password, connects to KDC and tries to receive initial TGT from it. Client).
I have an application server (webservice or remoting, not yet decided) on a remote machine and a client on the same domain. I want to authenticate the user as a domain user on the server.
I can ask the user to enter their Windows username/password and send those to the server and get the server to check them against Active Directory but I would rather not. Is there any way I can get the client to send some kind of token which the server can then use to identify which domain user is sending it a request? Obviously I want to protect the server against someone sending a fake user ID and impersonating another user.
Clarification
The client on computer A will communicate with the server on computer B. I think I will probably using .NET remoting for this communication. On the server I merely need to know the ID of the user on computer A; if the app on computer A must send the ID I need to be sure that it hasn't sent the ID of a different user.
I don't need to impersonate the other user, I merely need to know (for certain) who it is.
Are you saying that the client communicates against your server, and you need to use the client's privileges at a third server? That scenario describes The Double-Hop Problem. The blog most describes it in detail, and what can be done to circumvent it (domain modifications).
[...] you can get around the problem and use proper delegation if you set up your network to use Kerberos and set up the web server in question as trusted for delegation.
Added:
I know of no way you can identify the user on computer A. Would it be enough if it was just the user executing your program? You could use windows authentication in a domain scenario, but that would only give you the privileges used by the program to authenticate, which may differ from the actual evil user in front of the keyboard.
Added:
Your comments to this post indicates that windows authentication with impersonation would work for you. Check http://community.bartdesmet.net/blogs/bart/archive/2006/08/26/4277.aspx for code examples.
My question is pretty much summed up in the subject.The context is a problem we are facing with the account getting locked our fairly often.
My setup uses this as the service acccount for clearcase application.
There is another account by the same name (but in a different domain - a trusted domain) that runs a monitoring sofftware under this account. For eg., my setup uses the accoundt DOMAINA/clearcase_albd, while this other trusted domain runs a batch file under TRUSTEDDOMAIN/clearcase_albd.
We are suspecting this account to be causing the locking out of our service account (but at this point have not yet figured out why!)
Have pored over event logs endlessly, to no avail and have now decided to start fresh from ground zero.Am following a thread of thought and the first thing I need confirmation on is this:
Should I be seeing DOMAINA/clearcase_albd account when i run clearlicense at all?
If not, then why would another account by SAME name but from a different domain lock out my domain account?
Would greatly appreciate any help in this regard,
Thanks in advance
According to the IBM ClearCase Manual, the Rational® ClearCase® albd_server program runs with the identity of a special user account known as the Rational ClearCase server process user.
This user is a member of the Rational ClearCase administrators group, which grants privileged user status.
That account should not directly uses a license, as it is related to the albd (Atria Location Broker) process which will execute operation on behalf other users.
When a client program needs access to a service (a VOB or view server, for example) on a Rational ClearCase server host, it uses a remote procedure call (RPC) to send a request to the albd_server process on that host.
The albd_server starts the requested service if it is not already started, and provides the service’s port number to the client. Thereafter, the client communicates directly with the service.
IBM does suggest two albd accounts, for central VOB/view servers and end-user workstations. This is primarily done to prevent albd account issues (account lockouts, etc) on the albd account from impacting the VOB servers themselves.
BUT: those accounts should be on the same domain.
Note: by typing
creds clearcase_albd
You will see its SID for the current Windows domain.
You will then be able to check if that SID pops up in the clearlicense command output.