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.
Related
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.
We are currently facing an interesting issue with regard to Kerberos authentication.
The goal is to publish a website over the internet. The authentication needs to be handled from end-to-end by Kerberos in an Active Directory-environment. The client PCs, however, may or may not be domain-joined. The files of the website are located on a file share, which should be accessed using impersonation. The webserver itself is the primary domain controller.
The schematic overview of the landscape is shown below:
The problem:
IIS is set to only allow Negotiate:kerberos Windows Authentication. This will prompt a credential dialog in the browser when the client PC is outside the local network. The domain credentials are not accepted over the internet and the Client's eventviewer shows
The Kerberos client could not locate a domain controller for domain
domain.tld: 0xC000005E. Kerberos authentication requires communicating
with a domain controller.
This is correct, because the domain's KDC is not accessible over the internet. As far as we understand, Kerberos authentication should be possible with direct client access to the KDC, since the webserver is delegated to authenticate on behalf of the end user.
Our main assumption:
Kerberos can be used as an authentication method without direct access from the Client PC to the KDC.
The things we have tried and / or are relevant:
Sub.domain.tld is in Internet Explorer's trusted sites
Serveral SPN configurations
Different application pool identities (domain acount, default account, system, network)
Disable loopbackcheck
Machines in same time zone / same time
Enabled delegation for the web server
Reproduced on a different domain with different machines (this domain had seperate machines for the web server and the domain controller)
As a note, NTLM is not possible because it lacks support for impersonation and basic authentication is not desired because it stores the user credentials on the web server.
References:
www.adopenstatic.com/cs/blogs/ken/archive/2007/07/19/8460.aspx
www.adopenstatic.com/cs/blogs/ken/archive/2007/01/27/1282.aspx
windowsitpro.com/security/kerberos-delegation-and-troubleshooting
technet.microsoft.com/en-us/library/cc995228.aspx
community.dynamics.com/ax/b/axsolutionsmonkey/archive/2009/05/20/kerberos-configuration-for-clients-accessing-role-center-from-outside-of-intranet.aspx
dirteam.com/sander/2012/09/05/new-features-in-active-directory-domain-services-in-windows-server-2012-part-10-improved-kcd/
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
Is it possible, safe and practical to use Windows Integrated Security on an Extranet?
E.g. there is an IIS website on the intranet that can be used over the LAN with integrated authentication. When the user disconnects from the LAN he wants to be able to use the browser on his domain-joined-notebook to connect to the same website over the internet (no VPN) without having to logon separately.
The question of whether it's "safe" is a question of what additional security threats you're exposing the user to in the Internet scenario, that they weren't exposed to in the Intranet scenario. Additionally, are you exposing the server to additional security threats - and assuming that the question isn't "whether to allow access to the server from the Internet" but rather "which authentication methods should we allow for this server-now-exposed-to-the-Internet", this secondary question boils down to "is it better to use Windows integrated authentication protocols or require the use of Basic, Digest or digital certificates"?
Security threats to user/client: are the user's credentials reasonably protected from attackers who "sniff them from the wire"? Windows-integrated authentication uses either NTLM or Kerberos; in extranet scenarios, the user/client can't generally rely on Kerberos, since that would require transparent access to a KDC (i.e. an Active Directory domain controller) from the Internet as well. While this can be done, it's unusual to see a security-conscious organization allow that. So we're talking about NTLM - which hashes the user's password with a "nonce" (random set of characters) that are sent from the server, so that the user's password doesn't appear in plaintext over the wire. Compare NTLM to Basic and it's a clear win; compare NTLM to Digest authentication, and it's somewhat equivalent; compare NTLM to client certificate authentication, and certs always win for security (but lose on the deployment/bootstrapping challenges). Generally you'll find your security or server admins will want to use an SSL certificate for the IIS listener that's exposed to the Internet, so that user's credentials are even more protected against "sniffers". SSL is hardly perfect and doesn't protect against more sophisticated attackers in the middle (or someone who has a trojan/bot on the client device), but it costs very little for an extra layer of peace of mind. SSL + NTLM is a reasonable choice made by many.
Security threats to server: server is exposed to unauthorized attackers trying to gain access to authenticated resources. If the server allows any AD-authenticated authentication protocols then it's equally susceptible (or not) to attacks that try to brute force a user's password, and some sort of IDS solution that raises alarm bells for repeated bad password attempts is advisable (but quite a challenge to get the signal/noise ratio down to manageable levels). The server is also exposed to the possibility that any exploitable holes (primarily in IIS, or anything else exposed through the firewall) can be used to gain privileged access to the server by an outside attacker. Better be prepared for frequent patching. Other less likely but scary-sounding security threats are possible, but that's the big ones to tackle first.
Yes, it is definitely possible to use integrated security. But, it also depends on the framework you are using for authentication. In ASP.NET you can use built in authentication module. You to set the authentication mode to "Windows" and .Net will manage it for you. You can also have different roles for managing different types of users in your web app. You web app must be available outside your LAN(i.e. your firewall should not block incoming HTTP requests)
Vamyip
As ParanoidMike points out by exposing a webapplication to the internet that uses windows authentication you are creating a brute force attack vector to hackers. To try and mitigate this threat you should consider taking the following actions:
Restrict Access by IP address
Set Accounts to Lock out after n failed login attempts.
Admin accounts cannot be set to lockout so choose obscure usernames for them.
I'm currently investigating if it is possible to exclude admin accounts all together
When our customers install our software, they often opt for a "split install", where the services run on one box and the database is on another box. The services might talk to other services, or the database might contain stored procedures that need to talk to another database.
This leads us into the murky world of Kerberos and SetSPN.
I was about to send the support guys an email breaking down the difference between the various authentication levels supported by Windows, but I realised that my knowledge gets a bit vague about the difference between impersonate and delegate, and I'm really sketchy when it comes to Kerberos.
Can anyone enlighten me?
Authenticate (authn) means to identify a user. Authorize (authz) means to determine what rights an authenticated user has. An Anonymous user has not been authenticated but may have some rights on the system (a "guest"). Impersonate and delegate are two sides of the same coin. I impersonate you if I use your identity to do an action; you delegate me the right to impersonate you and take some action.
Kerberos (or "Kerb") is a token-based authentication scheme. That is, it's a way to let users log in and be properly identified (authn) and given rights (authz) in system.
Per comments: You don't need Kerb for delegation, but it's built in to Server 2003. You can also use NTLM, SSL Certificate Mapping or Digest Authentication. But none of those is as robust and flexible as Kerb. You also have the option to do constrained delegation which allows a delegation only to a certain services. The reason is that you need a trusted 3rd party to validate your token. Basically, the flow goes like this ...
I authenticate to my domain.
That domain issues a certificate to me. That cert makes claims about me.
I take that cert and give it to the service I want to allow me to do something
The service takes that cert and Valida's it with a trusted certificate authority
The service gives or denies access based on communication with the certificate authority
It's a deep subject as you know. :) Here is a good article on some of the above options. Also, check out this web cast -- it's about ADFS, but it does a good job on the concepts that might help.
You might want to brush up on Kerberos on Ken Schaefer's web site. His Kerberos FAQ rocks.
Adding to the above answer, delegation is having one server authenticate to another server using the client's original authentication. With Kereberos, this is relatively easy to accomplish - you just allow the first server to "re-issue" the client's authentication token. The alternative (NTLM) doesn't allow for delegation easily/securely since its a challenge/response authentication - the only way for the server to authenticate to the secondary server is if it can respond to the challenge/response, and to do that it would need the client's password.
I've got a ServerFault answer regarding Kerberos Delegation that might be interesting.