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.
Related
I'm working on an enterprise intranet .NET web application that needs several domains to be added to trusted sites to work properly (in Windows Internet Options). Is it possible to do this from web.config (rather than advising users to change their browser configuration)?
Thanks
May I know why are you going to add trusted website for clients?Did you get anything blocked?
Trusted sites are totally client side configuration.Its dangerous if server side can control your trusted site list.
So we can't do this via remote IIS server. Please promote trusted websites from ADDS group policy.What you can do from server side is just use a valid CA certificate for your website to make the connection secure.
https://social.technet.microsoft.com/Forums/lync/en-US/0baa6428-bf48-4e8a-82e1-b961918090d9/how-to-add-trusted-sites-to-group-policy?forum=winserverGP
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'd like to control certificate popup windows manually. For example, if an user wanna login with client-side-certificate, I prompts a certificate selection window; If he wanna login with username/password. System let him in without checking his certificate.
There are no standard APIs (or non-standard that I'm aware of) for controlling this with JavaScript or something similar.
The only solution I can think of is to have two webservers.
One for showing a web page that links to either the login form or the client certificate, and this server also implements the login form.
One that requires the user to specify a client certificate.
You could solve this using the same wildcard certificate for both servers and having them on different sub-domains so that you can actually back this setup by 2 different servers (IP addresses).
You can use the same actual physical server, and do "virtual host" dispatching based on the IP, and you can use the same wildcard SSL certificate for both.
The reason you need different servers is that the prompt for an SSL client certificate is triggered at the SSL handshake level, so you can't use name based virtual hosts, you need 2 actual servers to do it.
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.
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).