Can a computer that is NOT a part of the domain (but is on the network) authenticate against to a web site published by IIS8 where the authentication for that site is "Windows Authentication" only with a single provider of "Negotiate:Kerberos" (and with Kernel-mode authentication disabled)?
I ask because I am trying to do just this, but I cannot get past the authentication to the site (yet alone trying to pass the authentication to the database). I see the "WWW-Authenticate: Negotiate" header on the response to the client, but the client only ever seems to send a "NTLM Type1: Negotiation" (NTLMSSP) in the subsequent (re)requests. Either that or I am interpreting the results from Fiddler2 incorrectly!
I am using Kerberos as most of the clients will be domain computers and I need to pass user credentials from the web application back to the database. I was hoping that I would be able to do the same with non-domain computers and they would simply be prompted for a username/domain/password that would be validated and converted to a Kerberos ticket on the server.
Note that for testing purposes, Windows 8 is both the server and the client. In production, the server will be Windows 2008 Server R2 and the client will be primarily Windows 7 (though there will be some Windows 8 clients).
Kerberos will not work on accounts/computers which are not part of the domain.
You have two options to achive your goal:
Request the user data with Basic auth and pass that to LogonUserEx. See this for answers.
Authenticate the user by other means and use S4U2self (protocol transition).
Related
In Azure DevOps services, when you connect an agent to the server, you have different types of ways to authenticate to the server. You can see here for example, about connecting a Linux agent, that you have these 4 types:
Alternate (Basic authentication)
PAT
Negotiate - Connect as a user other than the signed-in user via a scheme such as Kerberos or NTLM.
Integrated - Not supported in Linux
The integrated type is mentioned in the page about connecting a Windows agent as "Windows default credentials"
Bare with me please.
In my organization, we have a Active Directory domain with a Single-Sign-On, I suppose it uses Kerberos as the authentication protocol. Sometimes I use Powershell scripts to access the API of our internal Azure DevOps Server, and I use the -UseDefaultCredentials flag so the user won't have to enter username and password - it will just authenticate based on the logged-in user.
That got me thinking that the -UseDefaultCredentials flag is using Kerberos to authenticate.
But from the above, it seems that Integrated is using "Default credentials", which is something else than "Negotiate" which uses Kerberos.
Can someone help me understand this?
The UseDefaultCredentials flag tells the underlying system to try and use the caller's SSO credentials, which in most cases is the credential used to log into the system interactively or otherwise.
Strictly speaking it does not indicate which protocol to use. What it's actually saying is "dear system internals: please figure it out for me". The way this works is by selecting the negotiate protocol, which as it's name suggests negotiates the use of specific authentication protocols based on the client credentials as well as information from the server. This is called the SPNEGO protocol. It is transparent to the caller.
SPNEGO is fairly simple in nature. The client has a list of known authentication protocols (Kerberos, NTLM, etc.) and will send that list to the server saying 'pick one please'. The server can select any of them and respond telling them what to use, and the client then goes and uses it. Fin.
SPNEGO is also relatively smart because it can reasonably predict what it thinks the server will accept and will attempt to optimistically provide a token up front using the first protocol in the list. So if it thinks it needs Kerberos it'll go and get a Kerberos ticket up front and send it first. The server might think that's fine, or it might fail and return a response saying
"no, I really need NTLM", and so the client tries again with NTLM.
We have an in-house OAuth2 server used by our applications. Now we want to use Windows SSO for our applications but without them to change anything: they'll still reach our OAuth2 server for an access token and the authentication part will be delegated to Kerberos (which Windows use, if I understood properly).
Is there a way to do that?
That is a standard setup and should just require configuration changes in the Authorization Server (AS) - with zero code changes in applications.
Most commonly:
The AS might be hosted in the cloud
It will redirect browsers to an on premise Identity Provider (IDP)
The IDP can connect to Active Directory
You may also need a fallback option for when users are not joined to the work domain. See this Curity guide for an example and some infrastructure factors to think about.
If the AS is in house it may even be able to make a direct Kerberos connection via an LDAP data source, though the preferred architecture is a separate IDP.
Of course you need an AS that supports the ability to make this type of connection, so would need to check the vendor docs.
REQUEST FLOW
Kerberos has always been the simplest protocol conceptually but the deepest to understand - here is a bit of a summary:
Your apps will make a standard OpenID Connect authorization redirect to the AS
The AS may then present an authentication selection screen to the user, unless there is only a single option
Alternatively an app can send the acr_values query parameter to say which authentication method to use
The AS will then redirect the browser to the next stage of processing, that uses a 'Windows SSO authenticator'
The redirect to the Windows SSO authenticator does not have to use OpenID Connect - it could be any vendor specific HTTP request
The browser will send an encrypted Kerberos ticket automatically by connecting to AD - a prerequisite for this to work might be that the domain in the URL is in the Local Intranet zone on end user computers
The Windows SSO authenticator will need to be able to decrypt this credential, which typically requires a Service Principal Name to be configured
Once the Kerberos ticket is decrypted, the authenticator will make an LDAP connection to an Active Directory data source via its standard LDAP endpoints, to verify the received ticket
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/
In my IE, when I want to access a SharePoint site, I'm asked for username/password (obviously).
Is there a way to make IE know that, when I access a domain XXX, it should use certain credentials? Even if I have to use a plugin.
I tried Windows Vault, but that doesn't seem to work with IE.
Add the domain to the "Local Intranet Sites" in security in IE. That will log in the current user that is logged into the PC.
You can set up a ADFS server (an Identity Provider) on the domain where your client is. The SAML or WS-Federation tokens issued from your source domain would be trusted by a second ADFS server (the Service Provider).
Here is what would happen when you would visit the SharePoint site:
You go to the SP site, "naked" (no kerberos, password or client certificate)
You are redirected to your local ADFS server
Your browser authenticates with a Kerberos ticket to the local ADFS server.
Local ADFS server issues a SAML or WS-Federation token and redirects you back to the "remote" SharePoint site
You go to the remote SharePoint site, with a POST containing a WS-Federation token.
Seeing the token, and trusting the signature or the source domain, access is granted.
But it is easier said than done. Things to look out for :
How will you link existing username password based accounts with shiny new ADFS logons ?
What if there are duplicate user names ?
Will that break authentication for remote users who are simply using Kerberos (because for them, it is a local SharePoint) ?
What is the impact should you change the URL so that users go to your ADFS server first ?
+Beware : the ADFS server role in Windows Server 2008 R2 will install ADFS 1.?. Do not use it. Download and install ADFS 2.0 or later.