I've got server with w2k8 and IIS7 in one domain and keytab from some other foreign domain (no trusts). Is it possible to enable Windows Authentification (SPNEGO/Kerberos) to auth users in Web Application from the those foreign domain?
It's theoretically possible, but the logistics of making it work are next to impossible to implement.
I've no idea if IIS supports this or not, but it is possible in the kerberos API to say
"try to decrypt this response using every key in the keytab". In theory, this can be used
with keys from remote realms, although I've never seen code attempt it.
However, the problem is the client needs to decide the realm and principal to use to make
the request based on information outside the protocol. Thus you'd need to somehow tell all the
web clients from the remote domain to use the remote domain when contacting the webserver
in the w2k8 domain. You can do this with krb5.conf on unix machines, but it would require a
custom krb5.conf on every client using identities from the remote realm.
In general, kerberos will only work across multiple realms if there is some kind of cross realm
trust enabled.
Related
I want to build a server using Node.js, which acts as some kind of proxy. The clients that connect to my server use NTLMv2 for authentication (there is no chance to change this), but the upstream server my server shall connect to requires a Kerberos token.
So, my question is pretty simple: How do I, using Node.js, transform the information provided by NTLMv2 into a Kerberos token? On npm, so far I have found modules for NTLMv2 authentication, but I somehow would probably need to talk to Windows to translate NTLMv2 data of a user into a token for this user.
Any hints on this, how to approach this problem?
Absolutely not! NTLM and Kerberos operate completely different. First of all, I would highly recommend get rid off NTLM as fast as you can.
You can solve your problem in an easy fashion if you can access C interfaces. I also assume you MIT Kerberos on a Unix-like OS like CentOS or FreeBSD, etc.
NTLM will provide you the downlevel logon name. You need first to convert the NetBIOS domain to a DNS domain via LDAP (use libopenldap) then you can construct the Kerberos principal or the enterprise principal for your client. Then create a service account in your KDC and enable protocol transition and contrained delegation on that account for the target service. Now request a TGT on behalf of that user principal and request a service ticket for the user, voila you can access your Kerberos backend.
Here is a decent read: https://k5wiki.kerberos.org/wiki/Projects/Services4User
If you run HTTPd as your reverse proxy, it might handle all the magic for your with mod_auth_gssapi.
On Windows, this is a bit of a pain with the security API and SSPI. While the the principal transformation comes for free with Windows. You'll need LsaLogonUser with KERB_S4U_LOGON, impersonate with that handle and then require SSPI to acquire a cred handle...
If your KDC allows constrained delegation, you can setup your intermedaite server to allow impersonation. This way it can established security context with the client in one mechanism (in your case, NTLM), and talk to the backend server on behalf of the client in another mechanism (Kerberos). Google for "constrained delegation" and "protocol transition" for more information. Hope this helps.
I'm planning to make the Tomcat (8.5) Manager accessible through a subdomain like this: https://tomcat.mydomain.com.
As you can see the connection is over HTTPS, but still, does this pose a security risk and is considered as 'bad practice'?
One think I did notice is that, by looking at the certificate for mydomain.com, you can see that https://tomcat.mydomain.com does exists. Which means there is not much security by obscurity.
Of course, it's important to have the tomcat accounts setup right and protected by a password, which I have.
Having the endpoint publicly accessible is not, in itself, a security risk. There are other considerations, though, that you might want to take into account when deciding whether or not to expose an administrative interface publicly:
How many people have credentials for the service?
Can all those people be trusted to have good passwords?
Can all those people be trusted not to re-use passwords across multiple sites?
Do you have lock-outs enabled (on by default if using Tomcat's authentication with the Manager app)?
Can the lock-outs be overwhelmed? (consider the lock-out implementation)
Do admins actually need public access to the Manager?
Are there additional layers of security you could add between the public and the management interface?
In general, I usually choose not to expose administrative interfaces to the public. I almost always require an administrative user to go through some other gate such as an ssh tunnel (with public-key-only access) before they can access any management interface, and then they most also authenticate a second time through that interface (i.e. you aren't automatically trusted just because you have the tunnel established).
If I were going to expose an administrative interface to the public, I think I would want something in addition to password-based authentication in the mix. Some other factor should be involved, whether that is something like a common 2FA solution like TOTP or similar, or TLS client certificates ("mutual authentication").
There is a presentation on the Tomcat web site about upgrading your credential security. There is sample code and configuration in there for how to set up TOTP within Tomcat's existing authentication system. You might want to read that presentation and consider whether you want to add protection like that to your administrative interfaces.
I built out a few applications - published intranet environment - and all of them are prompting for a username and password in order to access the application (connection to this site is not private).
I am not sure if this is an IIS Setting that needs to be adjusted, I have tried adding everything on my end with the web config settings. Even explicitly turning authentication off and allowing anonymous users, does not do anything.
So my main question is could this security prompt feature be turned off through IIS since the application web.config is yielding no results?
I have the default settings that visual studio generates along with my database connection string.
There's two different things here. First, the prompt is because Anonymous Authentication is not enabled. If you don't want any sort of authentication or authorization, you can simply enable that. However, more likely, since this is an intranet, you do actually want people to be authenticated; you just don't want them to have to "login". For that, you should enable Windows Authentication.
The second piece, "Your connection to this site is not private", is either because you're running on HTTP, rather than HTTPS, or you are using HTTPS, but don't have a valid SSL cert. The latter is a very common issue in intranet scenarios, since there's usually not a public domain you can bind a cert to. In that scenario, you need to generate a self-signed cert and install it on all machines that need to access the site. Alternatively, you can set up your own internal CA, such that you can issue and validate your own internal certificates.
In either case, the message is there to let the user know that communication with this site will not be encrypted, so sensitive things, like say a username and password, will be transmitted in plain-text and can therefore be intercepted by monitoring the network traffic. That may or may not be a concern for your intranet environment, but the message is not internet/intranet-specific.
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).
Our production web servers ARE NOT part of the domain, but we'd like people to be able to log in automatically since they are logged into the domain on their PC.
Is there anyway to get the browser (IE7+) to send the appropriate information to the server (IIS6) so I can retrieve the ServerVariables["AUTH_USER"] or ServerVariables["LOGON_USER"]?
I presume the answer is no since if I set the security for windows auth to "on" and anonymous access to "off", then the server wouldn't know what do do with any user information for a domain which it has no knowledge of. I just want to know for sure before I give the SSO team a "not possible" answer.
I have implemented IWA for one of my projects and I am afraid the answer is NO, you can't use it when the server is in other domain.
IIS won't be able to communicate to the server through IWA in this case.