I've created a small application which attempts to authenticate a user based on their username and password. This application works correctly when run on the same domain which Active Directory resides on.
I must now extend the application to also work on domains which are "closed" in terms of security and permissions. In other words, is there a way to run the application based on an administrator account, or an account which has the necessary permissions to access the Active Directory?
This is the code I have used to authenticate a user:
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, server + ":" + port))
{
if (pc.ValidateCredentials(username, password))
{
valid = true;
}
else
{
valid = false;
}
}
The above code works perfectly, however I would like to modify it so that it can communicate with the Active Directory database in an authenticated manner.
I have read numerous documentation and resources, but have not found anything. The closes I found was an article mentioning that IIS has to be set up and configured in a specific manner. However, my application is a simple C# application, and IIS is not being used.
If I understand the question properly, you want to execute ValidateCredentials using a different user than the current process' user.
I may be missing something, but have you tried modifying your code this way?
using (PrincipalContext pc =
new PrincipalContext(ContextType.Domain,
server + ":" + port,
specialAccountUsername,
specialAccountPassword))
{
return pc.ValidateCredentials(username, password);
}
It simply uses a constructor that takes the special account you are using for accessing the domain.
Related
I have an intranet application that authenticates users against active directory. In general it works fine when testing locally(i.e. from my dev machine using VS 2017) or running it off of IIS in app server ("Browse *:80") until I try to access it using its URL from my local machine. Then whatever user id I use to get user's detail info, nothing is displayed.
Also, this app is to be accessible to users in certain groups so application checks logged in user's group membership.
Here is how I have it set up in IIS and different scenarios I tested with:
I set authentication to "Windows Authentication", disabled anonymous
authentication and enabled AS.NET Impersonation. This works fine when
running from app server using localhost but when trying to access
from my local machine and supplying user's user id to get his/her
detail info, no details are displayed (fails to get any info from
AD).
If I enable anonymous authentication and set it to "Application Pool Identity" (i.e. Network Services), it displays my custom
"Access Denied" page, presumably because this user is not part of
allowed group.
If I enable anonymous authentication and select "Specific User", supplying my credentials, then everything works fine, from app server or from my local machine, with one caveat: no matter who is accessing the site, it shows my name as logged in user.
I am stumped ad would appreciate some hints.
Update - Added code to get user info
Code to get user's identity:
WindowsIdentity wiUser = WindowsIdentity.GetCurrent();
string sID = wiUser.Name.ToUpper();
Code to get user's AD info:
static string adDomain = "www.xxx.yyy.zzz";
static string adContainer = "DC=www,DC=xxx,DC=yyy,DC=zzz";
public static DataTable getUserADInfoDT(string sSearchStr)
{
DataTable dtResults = new DataTable();
dtResults.Columns.Add("ID");
dtResults.Columns.Add("FirstName");
...
dtResults.Columns.Add("Zip");
string adDomain = string.Empty;
string adContainer = string.Empty;
// create domain context
PrincipalContext adPrincipalContext = new PrincipalContext(ContextType.Domain, adDomain, adContainer);
using (adPrincipalContext)
{
// define a "query-by-example" principal
UserPrincipal qbeUser = new UserPrincipal(adPrincipalContext);
qbeUser.SamAccountName = sSearchStr.Trim().ToUpper();
// create principal searcher passing in the QBE principal
PrincipalSearcher srch = new PrincipalSearcher(qbeUser);
PrincipalSearchResult<Principal> psr = srch.FindAll();
// find all matches
foreach (var found in psr)
{
DataRow dr = dtResults.NewRow();
UserPrincipal up = (UserPrincipal)found;
DirectoryEntry de = (DirectoryEntry)up.GetUnderlyingObject();
dr["ID"] = de.Properties["SAMAccountName"].Value.ToString().ToUpper();
if (de.Properties["givenName"].Value != null)
dr["FirstName"] = de.Properties["givenName"].Value.ToString();
...
if (de.Properties["postalCode"].Value != null)
dr["Zip"] = de.Properties["postalCode"].Value.ToString();
dtResults.Rows.Add(dr);
//de.Close();
}
return dtResults;
}
}
WindowsIdentity.GetCurrent() will get the user account that the current process is running under. If the application is running in IIS, that will usually be the user account that the app pool is running under - not the user that logged in to your application.
If you use IIS Express for debugging locally, then IIS Express is running under your user account, so you wouldn't see a difference. But on the server you will.
That said, if you have impersonation turned on and working properly, then WindowsIdentity.GetCurrent() should return the user that logged in - since impersonation means that your app is now pretending to be that person. So this might mean that impersonation isn't setup right. But maybe you don't even need it. I've never personally found a need to use impersonation.
To get the user that logged into your app, you should use HttpRequest.Current.User or possibly just HttpContext.User if your app is ASP.NET MVC.
And there is actually an easier way to get a DirectoryEntry object for the user, without having to search for the username. You can bind directly to the SID of the user, which is information you already have:
var user = new DirectoryEntry(
$"LDAP://<SID={((WindowsIdentity) HttpContext.User.Identity).User.Value}>");
If your server is not joined to the same domain as your users, then you might need to include the domain name:
var user = new DirectoryEntry(
$"LDAP://www.xxx.yyy.zzz/<SID={((WindowsIdentity) HttpContext.User.Identity).User.Value}>");
Something else to keep in mind: DirectoryEntry keeps a cache of all the Properties. When you access a property that it doesn't have in the cache already, it will go out to AD and ask for every attribute with a value. That's a lot of useless data going over the network if you only need 3 attributes. So you can tell it to specifically ask for only those 4 attributes before you use them:
user.RefreshCache(new[] {"SAMAccountName", "givenName", "postalCode"});
I talked about this, and other points, in an article I wrote: Active Directory: Better Performance
Update: To verify if IIS is actually enforcing authentication for a page, you can do this in PowerShell (update the URL to what you need - and this requires at least PowerShell 3):
try { (Invoke-WebRequest "http://example.com/the/page").StatusCode }
catch { $_.Exception.Response.StatusCode.Value__}
That will output the status code of the reply. You should see 401, since that is how IIS challenges the browser to send credentials. If you see 200, then Windows Authentication is not working for that page.
I do this in PowerShell, since Chrome's dev tools won't even show you the 401 challenge.
I want to write a function in a windows service application to remove a given computer name from Active Directory.
The Windows service is running on a machine which is domain-joined to the DC. Currently I have logged in to this machine with domain admin account.
The Windows service is running under the security context of "NT AUTHORITY/SYSTEM" and this should not be changed, as there shouldn't be any user interaction after installing the application, meaning that admin shouldn't enter their credentials in services.
When I run the application with my newly added code to delete the computer account, it doesn't work. However, when I change the logon info on the Windows Service and update that with domain admin credentials, it's able to successfully remove the computer account from AD.
Below is [a shortened version of] the function used to delete computer accounts.
Is there any way I can modify the code to be able to remove Computer Accounts using the same security context (NT AUTHORITY/SYSTEM)?
private void DeleteComputerAccount(string CompName, DirectoryEntry DirEntry)
{
try
{
//Delete computer account
DirectorySearcher search = new DirectorySearcher(DirEntry, "(name=" + CompName + ")");
SearchResult res = search.FindOne();
res.GetDirectoryEntry().DeleteTree();
}
catch (Exception)
{
Throw();
}
}
Where DeleteComputerAccount is called:
DirectoryEntry dirEntry = new DirectoryEntry("LDAP://domain.contoso.com");
string compName = "MyWorkstation01";
DeleteComputerAccount(compName, dirEntry);
When a service runs as local system, it will access the network (and thus AD) in the security context of the host's computer account. You can delegate the computer account (or better, a group which the computer is a member of) the ability to delete objects from AD. This link has accurate advice on how to complete that task - http://sigkillit.com/2013/06/12/delegate-adddelete-computer-objects-in-ad/
While not what you asked, a couple other things stand out to me:
You're not filtering your search very well. You might get something other than what you want back. I'd suggest a filter like this instead: (&(objectClass=computer)(sAMAccountName=<PCName>$))
Local system is a lot of access. Could you run this as network service instead?
Background
We are transitioning to Claims-Based auth in our app (on .NET 4.5)
We currently have authentication via Asp.net membership & domain auth working correctly.
The domain portion looks like this (generalized a little):
var context = new PrincipalContext(ContextType.Domain, ADDomainName);
return context.ValidateCredentials(username, password);
Problem / Goal
Sometimes we (or some consultants we use) are on a VPN connection using machines that can see our domain servers, but that aren't members of our domain.
It would be a great help to test the app from a machine that isn't on the domain, rather than having to fire up a machine that is on the domain in order to check.
Question
Is there a way to perform domain authentication against a domain controller from a machine that isn't on the domain? I haven't been able to find any research on it thus far.
You can use LDAP authentication and specify credentials from your code:
using(var context = new PrincipalContext(ContextType.Domain, "mydomain", #"mydomain\serviceAcct", "serviceAcctPass"))
{
//Username and password for authentication.
return context.ValidateCredentials(username, password);
}
Or, run your authenticating server under runas /netonly, which lets you run with domain network credentials from a workgroup joined computer
rem if your server is standalone
runas /netonly /user:mydomain\consultantaccount C:\dev\sts\ipsts.exe
rem or you can have it in IIS Express:
runas /netonly /user:mydomain\consultantaccount "iisexpress /path:c:\dev\sts\ /port:9090 /clr:v2.0"
I will note that I have not actually checked whether /netonly will work in this context, so if you end up trying it, I'd be interested to hear if it worked.
I have the following C# code that connects to my domain server and performs some actions on it. Everything works fine on my computer and I can run all my commands just fine.
My questions is: what credentials are used for the connection to the server? I assume it uses the current users credentials. So my real question is will this work on a normal user. I am an admin and it works fine on my machine.
However I am wondering if the same would hold true for a non admin?
PrincipalContext AD = new PrincipalContext(ContextType.Domain, "172.18.4.4");
UserPrincipal u = new UserPrincipal(AD);
u.SamAccountName = Environment.UserName;
PrincipalSearcher search = new PrincipalSearcher(u);
UserPrincipal result = (UserPrincipal)search.FindOne();
If that code is running in a Windows app then the credentials used are the ones of the current Windows user and it should work fine in a domain. If the code is running in an ASP.NET site, then the credentials are the ones of the application pool in which the site is running. In this last case, you might need to play with the Identity of the app pool: LocalSystem, NetworkService...
In any of the previous cases, you can impersonate a user to run this code under: (look at the answer)
How to use LogonUser properly to impersonate domain user from workgroup client
I am using the solution discussed here to authenticate users against the active directory in my ASP.NET web application. I've written a simple ADMembershipProvider class thas is used together with FormsAuthentication. Works fine when running the project locally but when deployed to a server in the network, the ValidateUser call takes really long time (approx 20s).
//Assumes using System.DirectoryServices.AccountManagement
public override bool ValidateUser(string username, string password) {
using (var context = new PrincipalContext(ContextType.Domain)) {
return context.ValidateCredentials(username, password);
}
}
I tried to add name and container parameters as documented on msdn to the PrincipalContext constructor, but these parameters doesn't seem to have any effect whatsoever.
using (var context = new PrincipalContext(ContextType.Domain, "MyDomain", "OU=MyCompany,DC=some,DC=stuff")) {
return context.ValidateCredentials(username, password);
}
We have the same problem on at least two different servers in our network. The servers are connected to the AD and running OS Windows server 2003 SP2 (IIS6)
One idea I had was that the issue might be connected to the fact that our domain has some trusts to other domains, and that they are somehow involved when validating the user. However, the users we are trying to validate exists exclusively in "our" AD.
Hit this issue and had to use ValidateCredentials(string, string, ContextOptions) method to pass in proper enum combination to access our ActiveDirectory connection in our environment.