I would like to ask if somebody could explain me how exactly user/account is authenticated in following scenario:
SMB File Server is part of the domain
access to the File server is granted via domain accounts
Client is outside of the domain and firewalled only to see the File Server.
Client is going to use domain credentials to authenticate to the File Server.
My question is how the Kerberos tickets are created if Client is not having visibility to KDC/Domain Controllers? is it going to be the File Server acting as a client for the KDC or relay the request if yes how the credentials are stored on the File Server? Or will be other authentication method used in this case e.g. NTLM?
Thanks!
Tomas
Related
Is it possible to setup IIS Webdav with windows authentication and SSL on a non domain joined web server?
The web server is hosted in azure and accessible via https 443. The clients are domain users and need to authenticate with their domain credentials in order to read/write on the web server over the internet.
My logic tells me this is not possible as the web server doesn't have a authentication provider without being domain joined?
Many thanks for any answers...
I don't think you would be able to use Windows Authentication, but if you have LDAP access to your AD environment from the server, you could do Forms Authentication and authenticate the user via LDAP in the back end. It would require the users to type in their credentials though.
You can test access to any one of the LDAP ports in PowerShell with:
Test-NetConnection -ComputerName domain.com -Port 389
The LDAP ports are:
389: LDAP
636: LDAP over SSL
3268: Global Catalog - same as LDAP but reads the whole AD forest
3269: GC over SSL
Any one of those would do.
I have an ASP.NET MVC application that authenticates users against Active Directory.
As I understand this is the process happens when a user logs on to his computer:
User enters credentials on the local machine.
Local machine checks if it already has an authentication ticket for these credentials.
If not, it contacts the first ADS server it can find that offers kerberos authentication functions
The ADS machine checks the credentials against the LDAP database.
If they check out, kerberos returns a TGT (ticket-granting-ticket) to the client machine
For a certain duration set in AD (usually 8~10 hours) this TGT will bypass any credential checking in case the local machine user wishes to connect to resources that require permissions not present in his bare user account (i.e. group memberships, additional machine and share access, etc.)
My question is how does IIS know about the TGT when the browser is making a request to it for my app? Does the operating system send it out on every outbound http request to every single website?
The server (IIS) will indicate to the client (browser) that it needs to authenticate by returning an HTTP 401 error code with a WWW-Authenticate header. The client detects this and determines if it can correctly authenticate. The way this works is as follows:
Determine who the requestor is by checking it's Service Principal Name. It exists as {type}/{fully.qualified.domain}, e.g. HTTP/resource.domain.com. This SPN is mapped to a machine or service account in AD. If this SPN isn't registered, the client falls back to a lesser protocol like NTLM.
Local machine uses the TGT to request a service ticket from AD. AD validates the TGT and looks up the SPN in the request and if found creates a service ticket encrypted against the password of the account associated to the SPN.
Client sends the service ticket to the server via Authorization: Negotiate YII... header.
Server decrypts the service ticket using the password it's been provided, either through a domain join, Windows Service Run As config, or keytab.
Server transforms the contents of the decrypted service ticket into a Windows identity.
Identity is presented to the application.
This flow isn't inherently web-specific. This is how all services authenticate themselves when using Kerberos.
Problem: I want users from my corporate client to authenticate with my web server by using their local LDAP credentials. Users have a local desktop client that can authenticate with the local LDAP server. My server and the LDAP server do not talk to each other.
I know it is possible to authenticate on a web server using LDAP if the web server relays the LDAP request to a LDAP server. (User/desktop client connects to web server, sends credentials and web server interacts with LDAP server for authentication)
But is there a way for a desktop client to authenticate with a local LDAP server and then connect to a web server sending a token that would grant access to the web server? (user auths with ldap, sends ldap response to webserver)
I am not talking Oauth, which requires both servers to talk. In this case, the LDAP server is isolated from outside contact.
The big problem here is that you should never trust the client, even if you have written it yourself. Something like public/private authentication would (probably) not work as well, since the problem is not the encryption, but making sure the message came as "OK" from the LDAP server. A rogue client could fake the OK and sign it anyway.
If I understand your problem correctly, you're looking for a way to make your desktop client talk to your web application using the user's domain credentials.
This should be easy to do using something like ADFS. If you run ADFS inside your clients Active Directory domain, your desktop client can get a token from it using Kerberos. It can then use this token to authenticate with your web application.
You will need to configure your web application to trust tokens issued by the ADFS instance in your clients domain.
ADFS may work, but it is unnecessary. You should look into using SPNEGO as it does not require a ADFS infrastructure.
My understanding is that both JAAS and SQL Server can be configured to use kerberos in a domain environment, with an active directory server.
My understanding that JAAS gets the user credentials from the user or from a file at the time of the connection - asks the directory server for a ticket, and presents that to the server.
Where does the SQL Server Driver get its kerberos ticket from? (as it seems to be able to obtain creditentials from the users existing login). Does it get the user login ticket - or does it extract the credentials from the user's logged in session?
SQL Server Driver gets Kerberos tickets from TGT (ticket granting ticket). This TGT is a ticket that is part of user's logon session and can be used to get short lived tickets to authenticate to other services (E.g. SQL Server).
You can use "Kerbtrey" utility from Windows Server Resource kit to examine such tickets.
JAAS also uses the same tickets but it needs to be told to obtain tickets + configuration (E.g. name of Kerberos server) from file and that path is somewhat dependent on OS version.
SQL Server drivers uses Wind32 API to get tokens.
How can i restrict access to the admin/ section of my website? I can't limit it by IP address because we need to sometimes access the admin/ section from remote client locations (when giving a demo, etc).
there is of course, an admin username/password - but what else can i do?
Most applications just use a username/password for access control, and that's generally sufficient. Some that require extra security use two-factor authentication, which might mean using a token that you carry with you (e.g. a device that generates a token that's kept in sync with a server) or a token that is sent to you (e.g. the system sends a text message to your phone with a token that you have to type in in addition to your password).
An easier option is to authenticate using a client certificate; you can carry the cert around with you on a thumb drive in case you're at a remote location (just remember to remove the certificate from the remote machine when you're done).
Here's a nice write-up on client certificate authentication.
Another option is to only allow connections from your local network, and then use VPN to join a remote machine to a local network.
if the admin interface is in an seperate folder, you can use .htaccess and http auth. the same can be done using e.g. rails to restrict access to certain routes (controllers).