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.
Related
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 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/
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).
I'm in the process of rearranging our web-based systems, so that users will be able to log on to our systems through a Sharepoint front-end. Our single sign-on server is an Oracle SSO server that authenticates against the same domain as the sharepoint server does, but these two are currently 2 separate logins.
What I'm looking for is to configure this scenario:
A user logs in to the Sharepoint site, authenticating agains Active Directory through the TMG. This gives the user access to the sharepoint site, and this is all standard OOTB functionality. Then the user should be able to navigate into our other systems without a re-login (because the SSO configured for external authentication with the same AD, and therefore uses the same userbase).
So basically the users currently have to login twice with the same domain\user + password. I would like the SSO server to be able to read the cookie that was established in the first login, and use that instead of presenting the SSO login screen all over again.
Is it possible to share such a cookie between 2 different platforms on the same domain?
I have implemented a kerberos "Zero-sign-on" approach for the Oracle SSO server, but this only works as long as the user comes from a computer inside our domain. When the user logs on from the outside world (www) he will be prompted to login to sharepoint first, and then to the Oracle SSO.
I basically need the Oracle SSO Cookie to somehow read the Sharepoint Cookie that was established. Does this make sense?
I am running a asp .net web service on IIS7. The latter is running on a Windows 2008 R2 Server. IIS7/the web service is configured for asp .net impersonation. The worker process owner is set to NETWORK SERVICE.
The web service invokes sqlplus.exe impersonated with his/her domain account on the server. I can see that through the task manager. However, when sqlplus is started, oracle says the username/password is wrong.
sqlplus.exe is started like this: sqlplu.exe / . This works great if I manually log on the server with the user account and type the statement above, everything works great
I believe you're running into the "double hop" issue here.
Your first hop is using impersonation from the client's computer to the web server. The second hop is from the web server to your database server, where you're attempting to pass those same credentials along to the database.
When you manually log on and run the sqlplus statement, it's only a single hop from the web server to the database server.
The following is quoted from MSDN. Notice the recommendation to use basic authentication from the client to the web server.
The double-hop issue occurs when the
ASPX page attempts to use resources
located on a server that is different
from the IIS server. In our case, the
first "hop" is from the web browser
client to the IIS ASPX page; the
second hop is to Active Directory.
Active Directory requires a primary
token. Therefore, the IIS server must
know the password for the client to
pass a primary token to Active
Directory. If the IIS server has a
secondary token, the
NTAUTHORITY\ANONYMOUS account
credentials are used. This account is
not a domain account and has very
limited access to Active Directory.
The double-hop using a secondary token
occurs, for example, when the browser
client is authenticated to the IIS
ASPX page by using NTLM
authentication. In this example, the
IIS server has a hashed version of the
password as a result of using NTLM. If
IIS turns around and passes the
credentials to Active Directory, IIS
is passing a hashed password. Active
Directory cannot verify the password
so it uses NTAUTHORITY\ANONYMOUS LOGON
for authentication.
If your browser client uses Basic
authentication to authenticate to the
IIS ASPX page, the IIS server has the
client password and can make a primary
token to pass to Active Directory.
Active Directory can verify the
password and authenticate the domain
user.
http://msdn.microsoft.com/en-us/library/ms817871.aspx