I'm working on an ldap project in C# and all I'm doing is doing searches for users and pulling data that we need to be able to see on the fly. I'm creating an asp.net page for this. Right now I have it to where I have hard coded my own ldap username/password into my ldap search class but what I want is to be able to make it so anyone can login and then be able to search under there own credentials.
Where are some good starting guides or maybe some advice on how I can have them bind to ldap, and have it store that username/password somewhere safely so when they do the search, and ldap makes that connection it'll know to use their username/password.
This really depends on how the page will be executed. If you want a consistent login, then provide the username/password in the connection. Otherwise it will be implicitly passed by IIS for the web application. If you set up impersonate rights, it will pass the currently authenticated user's credentials when making the connection. If you do not set impersonate, then it will use the IIS account that's running the application. So it will need to be an account that has network access, as well as access to the directory on the IIS machine.
The thing to be aware of is that no matter what direction you choose, make sure it is an account that can traverse your LDAP store and can retrieve all the information you're looking to display. If you have the standard end users using their credentials, they generally can only pull back their own information, and not much else.
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.
I am making an intranet mvc app for in-house use. Only other guy in the shop is the server tech. I am told we have a domain controller and we use AD, every user is in groups. I'm pretty sure we use windows authentication (based on we have to log in to our workstation.
I'm not sure if I should be using the UserPrincipal in Directory Services, or the Current.User stuff in HTTPContext, or something else, for authenticating users. Only people in certain AD groups should be able to open the app.
Obviously I know nothing about app security stuff. I plan to hit the books, as soon as I figure out which "technology" I should be using. I also need to check users against specific groups. I almost had that figured out, but I am getting false when I know it should be true.
if (HttpContext.Current.User.IsInRole("MyADGroup"))
{
IsAdmin = true; //keeps returning false.
}
So what should I be looking into?
You can use this example to help you get started with Active Directory Roles.
Since the application is in-house, you don't want to stray far from Windows Authentication, but I do recommend looking into LDAP.
Connecting to an LDAP Server
Good luck!
You can hook up the internal application to use users and groups from AD by using the ActiveDirectoryMembershipProvider. Then simply authenticate against the provider instances (Membership.ValidateUser). This allows you to use AD as a backing store but isolates your application from an explicit dependence on it. This will also populate the UserPrincipal on the HttpContext.
I would recommend using this with a standard login form, though IIS will allow you to configure Windows authentication for the entire site. Using a standard login form along with AD-backed authentication allows you to maintain the decoupling and also expose some parts of the site as public pages by allowing anonymous access. This can be useful for things like application help and FAQs which might be useful to someone trying to log on but either disallowed by permission or using the incorrect credentials. Provides a better user experience as well.
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
My company develops an asp.net 4.0 website as part of our product. It is meant to be run within an organization (intranet).
I've been given some requirements, but I'm new to this stuff and am not exactly sure what I should be looking into. In general this is what I need to do (assuming the website is running within a Windows domain network)
Allow automatic login to our application for any user currently logged into a domain computer. (Don't show a login screen).
Somehow map our predefined ASP.NET Roles to user groups defined in the domain (I guess manually mapping this in some sort of XML file is fine).
Get the authenticated user's groups so I can figure out the proper role from the above mapping
Get the authenticated user's contact information if available in active directory
I've done some hunting on google, and so far I've seen info on using forms authentication with active directory, windows authentication, something called AD authentication, impersonation, etc.
I'm not really looking for info on how to do this (although any help would be appreciated) I'm more looking for someone to point me in the right direction based on these requirements.
Thanks.
To skip a login, you'll have to use integrated authentication. (Turn off annonymous access in IIS, and enable Windows authentication in your application: http://msdn.microsoft.com/en-us/library/532aee0e.aspx) Of course, this will only work in Internet Explorer, and there are security concerns even if you keep it all inside your intranet.
You can probably use an Active Directory membership provider to get the username into Page.User.Identity.
And you can use the System.DirectoryServices namespace to query AD. This is a good way to get the groups out and into a form you can use for a Role Provider, as well as your route to look up their information.
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