Right now we have AD/Exchange to manage all of our users logins/e-mail on-site at the office. The major app that everyone uses maintains its own login accounts and all users have a tendency to forget login information for at least one of the two logins.
What I'm considering doing is using AD to authenticate the user in the application so that they don't even have to login to the app after they've logged into their machine.
The problem is that there are small number of users that work off-site (the app can work over the internet) and just use the machine's local account (which is causing problems of its own).
What I'm wondering is, will using AD to authenticate users on-site still be an option if a user works off-site?
The answer to almost any question posed to a programmer is "Yes..." It's what comes after the ellipses that is important. You may not want to do the things that come after the ellipses.
Based on the information in your question I think the answer is "No" but there are several scenarios where we could change that to a "yes".
If the AD account is only being used to authenticate that a user knows the password, then you could make a web service, host it in your domain, set it up to use windows authentication and SSL, modify the application to prompt the user for credentials, and call a method in the web service using those credentials. In that scenario, a successful call to the web service means that the user is authenticated. You could use the user's credentials to continue from there.
Detecting weather the application needs to prompt the user for credentials or not could be done by attempting to call the web service with the user's logged in credentials first. If this call fails then you know you need to prompt the user.
Not knowing the rest of the details of your application however means that there are many scenarios where this would not be enough.
I have done something very similar to what I described above. My scenario was the reverse: the application worked over the internet but I wanted it to be easier to log in in the cases where the machine has domain membership.
As an aside, the members who work from home: are they using laptops that are part of the domain or are they using machines that are not connected? In this case you may be able to use cached credentials but you should ask that question over at ServerFault.
Yes, you can definitely do that. It'll be a bit of work though.
What your app would have to do is either find out automagically whether it's directly connected to the office LAN, or working away from the office. Or you could have the user tell you, of course :-)
If it's on the LAN, no problem - you authenticate against AD.
If it's away from the office, you could e.g. call a WCF service on the company LAN, pass your Windows credentials, and have it authenticate you against the company AD. If you provide the right set of credentials, you'll be authenticated and allowed to work - if you're not allowed to log in, the call to the WCF service would fail.
You could do this almost automatically by using Windows credentials - in which case the "remote" user would still have to log on to your domain and use his / her normal Windows credentials; or you can pass username/password over the wire to WCF, or even install a certificate on the remote user's machine that WCF will then map to an AD account on the server side.
The options are plentiful! :-)
Marc
Related
I am working for the DOD. The application they have requested is web based, and will be on their internal network. The request is for CAC authentication, which is easy enough... The remaining problem is authenticating a user. The CAC authentication is happening at the IIS level, so by the time the user gets to the application, all I am doing (or had planned on doing) is checking the ID on the CAC, and comparing it to a user table in the database. If the user exists (and has been approved), then they are off and running in the system. If they do not exist, then they are pushed to the registration screen.
Given my lack of experience with web development, I am unsure if I need to actually authenticate the user in some way beyond the CAC authentication, or if I can just manually assign roles to the user and let the roles dictate what can or cannot be done in the application. Windows authentication is not an option; while this application is internal for the military, it is accessible from different mil networks.
If I do indeed need to authenticate a user... this is where I run into trouble. I have not found anything that says there is a way to manually authenticate a user. I could use the standard ASP tables in the database, but it seems... messy... to include things that won't be used (meaning the password field would always be an empty string - why include it in the db if it isn't being used?).
Thanks in advance for any help... If there's links to where I can read more about the authentication process, those would be very much appreciated as will.
I'm working on several DOE projects that use the same idea. What we normally do for web applications is to enable Windows authentication on the app. This will allow pass-through of user credentials and keep out anyone without credentials.
I also like to add role based authorization into the mix and then use AD groups to allow/deny users on specific apps.
Scenario: I am creating an application which uses OAuth for authentication and I want to try and limit a user sharing their credentials with colleagues (we charge per seat). The only way I could think of this was to store the IP with the token (although I'm aware multiple users from a single client could be on the same IP).
Is there a standard way of doing this in OAuth?
Not via any feature specific to OAuth. A valid user that logs on from the office or from home will have a different IP address. How would you distinguish that from another user that has someone else their credentials?
The only way I see to make this work is require two-factor authentication. It's much less likely your users will be prepared to share for example their phone to use your application.
Just make sure your application adds enough value that your users will want their own account and not share credentials.
Our client requested from us to make our web application accessible from Intranet and Internet.
When user tried to access the website from Intranet, The user should be logged in immediately (Windows Auth) ... The user should have public access also (e.g. Home, Coffee shop), But in this case he should use his credentials and the server will check if its valid.
Any advises?
This is the standard way Integrated Windows Authentication works. If you're inside the intranet (logged onto the domain), IE will automatically send your credentials when the website returns 401.2 (no auth method specified). When you're not inside the domain, the credentials will have to be prompted for, since the domain server cannot be contacted from the client machine.
This is not the same as the "tricky" solution you referred to. That solution is tricky because it also uses forms authentication, which you don't need here (AFAIK).
We decided not to use Windows Auth at all.
The customer want to stay logged in if he is in the Intranet.
so we did the following (and the customer is ok with that)
Forms Auth + 'Keeps me logged in' checkbox
Validate Credentials with AD.
Check if User in trusted IP Addresses Range (Something like allowed IP addresses in SQL Azure)
If trusted IP Range, user becomes authenticated.
If its not, Two factor auth by sending SMS.
One more reason for not using Windows Auth.
The user want to log-out at anytime to use different credentials to do some special tasks.
Usually customers do not know what exactly they want, so we will start dreaming and make things complicated. 'Simply keeps me logged in' for trusted IP addresses and he will stay logged in for N days.
I am implementing a C# MVC 4 application hosted in IIS 7.5 to replace the company intranet. The requirement is that when a user is at their personal workstation logged in with their windows credentials they will not be prompted to login(this is not optional the customer is firm on this as they believe this is how SharePoint works. Though I cannot confirm), however when they are on a mobile device or on a personal computer off the local network they will be promoted for their credentials. Also, while off the network the user should be able to log out, and the application should log out automatically after a period of inactivity. All users who have access to the application will have AD credentials.
I attempted to get a working solution with windows authentication, but it is my understanding that windows authentication is not intended for use outside a local network. Even if I could get the desired authentication results with this option there is no ability to log out without a significant amount of kludge and hacking with JS.
It appears that by default forms authentication is the answer, but is there a way to utilize the users windows credentials and authenticate against active directory with those without prompting the user to login while on the network?
Unfortunately even after I called Microsoft I was unable to find a good work around for this issue. They did suggest Active Directory Federation Service. This was not an option for us.
There is also a great blog post that does the opposite of what I am looking for but could probably be manipulated to work.
After working with my product owner we settled on a true forms authentication model. The way I was able to appease them was for users on the local network I am setting the time out for the forms authentication token and cookie to a longer duration and refreshing the duration so that if users are active on the application often enough they may never be prompted to log in.
This may not be the most elegant solution, but it has allowed us to meet the requirements set by the product owner. If anyone has additional suggestions I would love to hear them.
Could anyone please share any thought on authenticating Active Directory users using the AuthType.Kerberos method.
Ideally, I would like to pass the Username and Password to validate the user credentials using the AuthType.Kerberos method
This type of validation uses LDAP connection (LdapConnection)
Any comments or feedback will be very appreciated.
Cheers! :)
Kerberos doesnt use a username and password in the sense you are talking about here, it uses a ticket based auth system with a central server. Kerberos is quite complicated to implement and is normally only used in cases where you want to do double hop authentication with the logged in user. This means the application wants to use the credentials of the user who has logged in to access a secondry system. For example if you have a SharePoint site which pulls data from exchange server you may want to pass the currently logged in users details from sharepoint to exchange. This is normally done with Kerberos and Constrained Delegation.
In reality what you probably want for your application is Windows authentication (NTLM) which allows the application to authenticate domain users, (However again in the common case this doesnt use a username and password at your application level either).
===EDIT===
To implement kerberos with a .Net webapp you will need to do the following
Enable Constrained delegation for the app pool http://blogs.msdn.com/b/dotnetremoting/archive/2006/07/06/662599.aspx
Setup SPN's for your site http://support.microsoft.com/kb/929650
Setup your code to use kerberos when you call the remote service, this is basically just setting the protocol. You dont need to actually send the username or password
This article has some good advice around how to troubleshoot problems with the system
http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx