Develop Reference

Simple means to get user's roles from AD?

I am writing a standalone application that needs to, given a AD account name, figure out if the user is a member of a particular group. I am writing the application in .NET (C#). The structure in AD looks like this:
Organization
Team 1
David (user)
Groups
Application A
Team 1 (group from above)
Just listing the memberships for David will not show that he is a member of the Application A group.
I understand from Microsoft's documentation that (using the principals) I could simply use the IsInRole call, but I cannot find any case that doesn't require David to be logged on to the machine or running the application performing the check. I think my limited understanding of the security model also comes into play here.
Could someone please point me in the right direction? What I am looking for is hints on how to solve above (references, tips, snippets) in C#, without depending on David having to run any application.
Let me know if anything can be clarified.

Add a reference to DirectoryServices.AccountManagement
Then add a using statement:
using System.DirectoryServices.AccountManagement;
Then in your main procedure (or somewhere else, where required, call the Procedure IsMember:
string userName = "David";
string GroupName = "Team 1";
bool test = IsMember(userName, GroupName);
public static bool IsMember(string UserName, string GroupName)
{
try
{
UserPrincipal user = UserPrincipal.FindByIdentity(
new PrincipalContext(ContextType.Domain),
UserName);
foreach (Principal result in user.GetAuthorizationGroups())
{
if (string.Compare(result.Name, GroupName, true) == 0)
return true;
}
return false;
}
catch (Exception E)
{
throw E;
}
}
If David is in Team 1, the procedure will return true, otherwise false.

You can use UserPrincipal.FindByIdentity to obtain a UserPrincipal object from the directory. This isn't exactly like the other principal objects you may have found, but it does have an IsMemberOf method to allow you to query group membership.

I use this in my AD environment
var pc = new PrincipalContext(ContextType.Domain);
var group = GroupPrincipal.FindByIdentity(pc, "GROUPNAME");
var existsInGroup = group.GetMembers(true).Where(p => p.UserPrincipalName == "username#domain").Any();
If you don't want to check subgroups, pass false to GetMembers.
It doesn't require given user has to be logged on. Hope it helps.

Create Active Directory user in .NET (C#)

I need to create a new user in Active Directory. I have found several examples like the following:
using System;
using System.DirectoryServices;
namespace test {
class Program {
static void Main(string[] args) {
try {
string path = "LDAP://OU=x,DC=y,DC=com";
string username = "johndoe";
using (DirectoryEntry ou = new DirectoryEntry(path)) {
DirectoryEntry user = ou.Children.Add("CN=" + username, "user");
user.Properties["sAMAccountName"].Add(username);
ou.CommitChanges();
}
}
catch (Exception exc) {
Console.WriteLine(exc.Message);
}
}
}
}
When I run this code I get no errors, but no new user is created.
The account I'm running the test with has sufficient privileges to create a user in the target Organizational Unit.
Am I missing something (possibly some required attribute of the user object)?
Any ideas why the code does not give exceptions?
EDIT
The following worked for me:
int NORMAL_ACCOUNT = 0x200;
int PWD_NOTREQD = 0x20;
DirectoryEntry user = ou.Children.Add("CN=" + username, "user");
user.Properties["sAMAccountName"].Value = username;
user.Properties["userAccountControl"].Value = NORMAL_ACCOUNT | PWD_NOTREQD;
user.CommitChanges();
So there were actually a couple of problems:
CommitChanges must be called on user (thanks Rob)
The password policy was preventing the user to be created (thanks Marc)

I think you are calling CommitChanges on the wrong DirectoryEntry. In the MSDN documentation (http://msdn.microsoft.com/en-us/library/system.directoryservices.directoryentries.add.aspx) it states the following (emphasis added by me)
You must call the CommitChanges method on the new entry to make the creation permanent. When you call this method, you can then set mandatory property values on the new entry. The providers each have different requirements for properties that need to be set before a call to the CommitChanges method is made. If those requirements are not met, the provider might throw an exception. Check with your provider to determine which properties must be set before committing changes.
So if you change your code to user.CommitChanges() it should work, if you need to set more properties than just the account name then you should get an exception.
Since you're currently calling CommitChanges() on the OU which hasn't been altered there will be no exceptions.

Assuming your OU path OU=x,DC=y,DC=com really exists - it should work :-)
Things to check:
you're adding a value to the "samAccountName" - why don't you just set its value:
user.Properties["sAMAccountName"].Value = username;
Otherwise you might end up with several samAccountNames - and that won't work.....
you're not setting the userAccountControl property to anything - try using:
user.Properties["userAccountControl"].Value = 512; // normal account
do you have multiple domain controllers in your org? If you, and you're using this "server-less" binding (not specifying any server in the LDAP path), you could be surprised where the user gets created :-) and it'll take several minutes up to half an hour to synchronize across the whole network
do you have a strict password policy in place? Maybe that's the problem. I recall we used to have to create the user with the "doesn't require password" option first, do a first .CommitChanges(), then create a powerful enough password, set it on the user, and remove that user option.
Marc

Check the below code
DirectoryEntry ouEntry = new DirectoryEntry("LDAP://OU=TestOU,DC=TestDomain,DC=local");
for (int i = 3; i < 6; i++)
{
try
{
DirectoryEntry childEntry = ouEntry.Children.Add("CN=TestUser" + i, "user");
childEntry.CommitChanges();
ouEntry.CommitChanges();
childEntry.Invoke("SetPassword", new object[] { "password" });
childEntry.CommitChanges();
}
catch (Exception ex)
{
}
}

How to check if Windows user account name exists in domain?

What is the simplest and most efficient way in C# to check if a Windows user account name exists? This is in a domain environment.
Input: user name in [domain]/[user] format (e.g. "mycompany\bob")
Output: True if the user name exists, false if not.
I did find this article but the examples there are related to authenticating and manipulating user accounts, and they assume you already have a user distinguished name, whereas I am starting with the user account name.
I'm sure I can figure this out using AD, but before I do so I was wondering if there is a simple higher level API that does what I need.
* UPDATE *
There are probably many ways to do this, Russ posted one that could work but I couldn't figure out how to tweak it to work in my environment. I did find a different approach, using the WinNT provider that did the job for me:
public static bool UserInDomain(string username, string domain)
{
string path = String.Format("WinNT://{0}/{1},user", domain, username);
try
{
DirectoryEntry.Exists(path);
return true;
}
catch (Exception)
{
// For WinNT provider DirectoryEntry.Exists throws an exception
// instead of returning false so we need to trap it.
return false;
}
}
P.S.
For those who aren't familiar with the API used above: you need to add a reference to System.DirectoryServices to use it.
The link I found that helped me with this: How Can I Get User Information Using ADSI
The examples use ADSI but can be applied to .NET DirectoryServices as well. They also demonstrate other properties of the user object that may be useful.

The System.DirectoryServices namespace in the article is exactly what you need and intended for this purpose. If I recall correctly, it is a wrapper around the Active Directory Server Interfaces COM interfaces
EDIT:
Something like the following should do it (it could probably do with some checking and handling). It will use the domain of the current security context to find a domain controller, but this could easily be amended to pass in a named server.
public bool UserInDomain(string username, string domain)
{
string LDAPString = string.Empty;
string[] domainComponents = domain.Split('.');
StringBuilder builder = new StringBuilder();
for (int i = 0; i < domainComponents.Length; i++)
{
builder.AppendFormat(",dc={0}", domainComponents[i]);
}
if (builder.Length > 0)
LDAPString = builder.ToString(1, builder.Length - 1);
DirectoryEntry entry = new DirectoryEntry("LDAP://" + LDAPString);
DirectorySearcher searcher = new DirectorySearcher(entry);
searcher.Filter = "sAMAccountName=" + username;
SearchResult result = searcher.FindOne();
return result != null;
}
and tested with the following
Console.WriteLine(UserInDomain("username","MyDomain.com").ToString());

Found a simple way to do this if you're on a high enough framework version:
using System.DirectoryServices.AccountManagement;
bool UserExists(string userName, string domain) {
using (var pc = new PrincipalContext(ContextType.Domain, domain))
using (var p = Principal.FindByIdentity(pc, IdentityType.SamAccountName, userName)) {
return p != null;
}
}

What is the best way to get the current user's SID?

Prerequisite Detail
Working in .NET 2.0.
The code is in a common library that could be called from ASP.Net, Windows Forms, or a Console application.
Running in a Windows Domain on a corporate network.
The Question
What is the best way to get the current user's SID? I'm not talking about the identity that is executing the application, but the user who is accessing the interface. In background applications and desktop based applications this should be the identity actually executing the application, but in ASP.Net (without impersionation) this should be the HttpContext.Current.User SID.
The Current Method
This is what I've got right now. It just seems... wrong. It's nasty. Is there a better way to do this, or some built in class that does it for you?
public static SecurityIdentifier SID
{
get
{
WindowsIdentity identity = null;
if (HttpContext.Current == null)
{
identity = WindowsIdentity.GetCurrent();
}
else
{
identity = HttpContext.Current.User.Identity as WindowsIdentity;
}
return identity.User;
}
}

I don't think there is a better way at getting at this info--you've got to get at the WindowsPrincipal somehow and .NET's rather clean API abstracts that behind the User object. I'd just leave this nice and wrapped up in a method and call it a day.
Well, ok, there is one thing you should do (unless your web users are always going to be WindowsIdentity), which would be to check for null identity and handle it according to whatever rules you have.

Without the use of third-party libraries This code will give correct results, if the user changed his user name.
String SID = "";
string currentUserName = System.Security.Principal.WindowsIdentity.GetCurrent().Name.ToString();
RegistryKey regDir = Registry.LocalMachine;
using (RegistryKey regKey = regDir.OpenSubKey(#"SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData", true))
{
if (regKey != null)
{
string[] valueNames = regKey.GetSubKeyNames();
for (int i = 0; i < valueNames.Length; i++)
{
using (RegistryKey key = regKey.OpenSubKey(valueNames[i], true))
{
string[] names = key.GetValueNames();
for (int e = 0; e < names.Length; e++)
{
if (names[e] == "LoggedOnSAMUser")
{
if (key.GetValue(names[e]).ToString() == currentUserName)
SID = key.GetValue("LoggedOnUserSID").ToString();
}
}
}
}
}
}MessageBox.Show(SID);

The WindowsIdentity class is the "built in class that does it for you". You've got as simple a solution as you're going to get really, as long as you have a valid WindowsIdentity to work with.
Alternatively, if you have the username of the user in question and you want to get the SID directly from AD, you can build your own library to use the DirectoryServices namespace and retrieve the DirectoryEntry for your user (this is a fairly complicated process as DirectoryServices is tricky). You can even use LDAP to get it if you have a need.

//the current user
WindowsIdentity.GetCurrent().Owner
Returns the security identifier (SID) in SDDL format
you know them as S-1-5-9.
WindowsIdentity.GetCurrent().Owner.ToString()
Returns the account domain security identifier (SID)
If the SID does not represent a Windows account SID, this
property returns null
WindowsIdentity.GetCurrent().Owner.AccountDomainSid
You could use this as:
_pipeSecurity = new PipeSecurity();
var sid = new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, WindowsIdentity.GetCurrent().Owner);
var audid = new PipeAuditRule(sid, PipeAccessRights.FullControl, AuditFlags.Failure | AuditFlags.Success);
var access = new PipeAccessRule(sid, PipeAccessRights.ReadWrite, AccessControlType.Allow);
_pipeSecurity.AddAuditRule(audid);
_pipeSecurity.AddAccessRule(access);

How can I tell if my process is running as Administrator?

I would like to display some extra UI elements when the process is being run as Administrator as opposed to when it isn't, similar to how Visual Studio 2008 displays 'Administrator' in its title bar when running as admin. How can I tell?

Technically, if you want to see if the member is the local administrator account, then you can get the security identifier (SID) of the current user through the User property on the WindowsIdentity class, like so (the static GetCurrent method gets the current Windows user):
WindowsIdentity windowsIdentity = WindowsIdentity.GetCurrent();
string sid = windowsIdentity.User.ToString();
The User property returns the SID of the user which has a number of predefined values for various groups and users.
Then you would check to see if the SID has the following pattern, indicating it is the local administrator account (which is a well-known SID):
S-1-5-{other SID parts}-500
Or, if you don't want to parse strings, you can use the SecurityIdentifier class:
// Get the built-in administrator account.
var sid = new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid,
null);
// Compare to the current user.
bool isBuiltInAdmin = (windowsIdentity.User == sid);
However, I suspect that what you really want to know is if the current user is a member of the administrators group for the local machine. You can get this SID using the WellKnownSidType of BuiltinAdministratorsSid:
// Get the SID of the admin group on the local machine.
var localAdminGroupSid = new SecurityIdentifier(
WellKnownSidType.BuiltinAdministratorsSid, null);
Then you can check the Groups property on the WindowsIdentity of the user to see if that user is a member of the local admin group, like so:
bool isLocalAdmin = windowsIdentity.Groups.
Select(g => (SecurityIdentifier) g.Translate(typeof(SecurityIdentifier))).
Any(s => s == localAdminGroupSid);

I think this is a good simple mechanism.
using System.Security.Principal;
WindowsIdentity identity = WindowsIdentity.GetCurrent();
WindowsPrincipal principal = new WindowsPrincipal(identity);
bool isAdmin = principal.IsInRole(WindowsBuiltInRole.Administrator);

Here's a one liner to do it.
using System.Security.Principal;
static bool IsElevated => new WindowsPrincipal(WindowsIdentity.GetCurrent()).IsInRole(WindowsBuiltInRole.Administrator);

I felt it important to note the difficulty I had with attempting to use WellKnownSidType.BuiltinAdministratorsSid per casperOne's answer above. According to the WellKnownSiDType MSDN, BuiltinAdministratorsSid "Indicates a SID that matches the administrator account." So I would expect casperOne's code to work, and guess it likely does in some environments. Unfortunately, it didn't on my Windows 2003 with .NET 2.0 (legacy code). It actually returned S-1-5-32-544 which, according to this article is the sid for the Administrators group. Thus, the comparison fails for me. I will have to do my own string comparison for startswith "S-1-5-21" (that kb 243330 indicates the "21" is included even though the blog referenced above does not) and endswith "500".

I hope you solved it, I was looking for someone smart to solve my NamedPipe permission issue, perhaps someone in 2022 likes my answer to your 13-year-old question...
using .net 6.0 > win7 or later ...
Perhaps do something like this and test if what you see makes sense on your account:
var user = WindowsIdentity.GetCurrent();
if (user is not null)
{
logger.LogInformation("{User}", user.Name);
foreach (var item in Enum.GetValues<WellKnownSidType>())
{
try
{
var sid = new SecurityIdentifier(item, user.Owner);
logger.LogInformation($"IsIsWellKnown({item}): {user.Claims.Any(a=> a.Value == sid.Value)}");
}
catch { }
}
}
then if it does you can use something like this:
public static bool Is(WindowsIdentity user, WellKnownSidType type)
{
var sid = new SecurityIdentifier(type, user.Owner);
return user.Claims.Any(a => a.Value == sid.Value);
}
You could be really smart about it and make an extension method by adding the this keyword
public static bool Is(this WindowsIdentity user, WellKnownSidType type)
{
var sid = new SecurityIdentifier(type, user.Owner);
return user.Claims.Any(a => a.Value == sid.Value);
}
You could then use it like so:
WindowsIdentity.GetCurrent().Is(WellKnownSidType.AccountDomainAdminsSid))

I use simple try catch statement to create a random file in "C:\Windows\" folder. If it errors out the app is running with normal privileges otherwise it is running as admin privileges.
try
{
File.Create(string.Format(#"C:\Windows\{0}.txt", new Guid()), 0, FileOptions.DeleteOnClose);
// Do as admin
}
catch
{
// Do as default
}