Active Directory querying

Active Directory querying

I'm working on a webpage app in Asp.Net that will communicate with a
local Active Directory (Win 2000) server, and return details for a list
of users, a single user's details, etc.

Currently, the application returns results for only a select group of
users instead of any valid username/password combination that I would
provide. Mistyped username/password combinations will throw an
exception, so I know that is not the case. The only common difference
between the user accounts that return results and the ones that don't
is based on whether or not an Exchange account has been made for the
user (ie: those with Exchange accounts will have all of their details
returned). Group policy associations, such as Administrators, Domain
Admins, and even normal users, does not seem to affect whether or not I
get data returned.

While I can post the exact code, most of my progress with connecting to
AD has been made based on the following two source webpages:
http://www.c-sharpcorner.com/Code/2...e/ADand.NET.asp
http://www.upyourasp.net/articles/article.aspx?aid=13

Does this make sense at all? This common denominator between the
working and non-working accounts goes against what was stated in the
first listed link, which is that normal users will have at least
read-only capabilities for polling AD, which is all that I am trying
right now.

Any advice or suggestions is greatly appreciated!

date: 19 Oct 2005 12:37:04 -0700 author: PTNL

Re: Active Directory querying

Can you just show a simple sample that shows how you are building the 
DirectoryEntry for the search root object and what your filter looks like?

Joe K.

"PTNL"  wrote in message 
news:1129750624.676101.217630@o13g2000cwo.googlegroups.com...
> I'm working on a webpage app in Asp.Net that will communicate with a
> local Active Directory (Win 2000) server, and return details for a list
> of users, a single user's details, etc.
>
> Currently, the application returns results for only a select group of
> users instead of any valid username/password combination that I would
> provide. Mistyped username/password combinations will throw an
> exception, so I know that is not the case. The only common difference
> between the user accounts that return results and the ones that don't
> is based on whether or not an Exchange account has been made for the
> user (ie: those with Exchange accounts will have all of their details
> returned). Group policy associations, such as Administrators, Domain
> Admins, and even normal users, does not seem to affect whether or not I
> get data returned.
>
> While I can post the exact code, most of my progress with connecting to
> AD has been made based on the following two source webpages:
> http://www.c-sharpcorner.com/Code/2...e/ADand.NET.asp
> http://www.upyourasp.net/articles/article.aspx?aid=13
>
> Does this make sense at all? This common denominator between the
> working and non-working accounts goes against what was stated in the
> first listed link, which is that normal users will have at least
> read-only capabilities for polling AD, which is all that I am trying
> right now.
>
> Any advice or suggestions is greatly appreciated!
>

date: Thu, 20 Oct 2005 23:24:51 -0500 author: Joe Kaplan \(MVP - ADSI\)

Re: Active Directory querying

Sample Code (C# in code-behind):


DirectoryEntry entry = new DirectoryEntry();
DirectorySearcher searcher = new DirectorySearcher();
SearchResultCollection results;
ResultPropertyCollection properties;
StringBuilder sb = new StringBuilder("");
string username = txtUsername.Text.Trim();
string password = txtPassword.Text.Trim();
string activeDirectoryType = ddlADType.SelectedItem.Text.Trim();

entry.Path = @"LDAP://192.168.1.1/DC=MyDomain;DC=MyCompany;DC=Com";
entry.Username = "MyDomain\\" + username;
entry.Password = password;

searcher.SearchRoot = entry;
searcher.Filter = "(&(objectClass=user)(cn=" + username + "))";
results = searcher.FindAll();

if (results.Count == 0)
{
	returnValue = false;
	sb.Append(results.Count.ToString() + " matching user(s) found.");
}
else
{
	properties = results[0].Properties;

	sb.Append(results.Count.ToString() + " matching user(s) found.");
	sb.Append("<br>");
	sb.Append("<hr>");
	sb.Append("<br>");
	sb.Append("<b>::DirectoryEntries::</b><br>");
	foreach (DirectoryEntry child in entry.Children)
	{
		sb.Append("<br>");
		sb.Append(child.Name);
	}
	sb.Append("<hr>");
	sb.Append("<br>");
	sb.Append("<b>::Properties::</b><br>");
	foreach (string key in properties.PropertyNames)
	{
		foreach (object objProp in properties[key])
		{
			sb.Append("<br>");
			sb.Append(key.ToUpper() + "=" + Convert.ToString(objProp));
		}
		sb.Append("<br>");
		sb.Append("~~~");
	}
}

date: 21 Oct 2005 06:16:05 -0700 author: PTNL

Re: Active Directory querying

Is it possible that the CN is not equal to the sAMAccountName (the logon 
name) for some of the users in question?  It is common for accounts to be 
created with those attributes the same, but they by no means have to be. 
However, your code is definitely assuming that.

What happens if you change the filter to:
(sAMAccountName=xxxx)

Note that I probably would not even bother adding (objectClass=user) clause 
in the query as objectClass isn't indexed and sAMAccountName is and is 
guaranteed unique on the domain.

Joe K.

"PTNL"  wrote in message 
news:1129900565.670366.197130@g44g2000cwa.googlegroups.com...
> Sample Code (C# in code-behind):
>
>
> DirectoryEntry entry = new DirectoryEntry();
> DirectorySearcher searcher = new DirectorySearcher();
> SearchResultCollection results;
> ResultPropertyCollection properties;
> StringBuilder sb = new StringBuilder("");
> string username = txtUsername.Text.Trim();
> string password = txtPassword.Text.Trim();
> string activeDirectoryType = ddlADType.SelectedItem.Text.Trim();
>
> entry.Path = @"LDAP://192.168.1.1/DC=MyDomain;DC=MyCompany;DC=Com";
> entry.Username = "MyDomain\\" + username;
> entry.Password = password;
>
> searcher.SearchRoot = entry;
> searcher.Filter = "(&(objectClass=user)(cn=" + username + "))";
> results = searcher.FindAll();
>
> if (results.Count == 0)
> {
> returnValue = false;
> sb.Append(results.Count.ToString() + " matching user(s) found.");
> }
> else
> {
> properties = results[0].Properties;
>
> sb.Append(results.Count.ToString() + " matching user(s) found.");
> sb.Append("<br>");
> sb.Append("<hr>");
> sb.Append("<br>");
> sb.Append("<b>::DirectoryEntries::</b><br>");
> foreach (DirectoryEntry child in entry.Children)
> {
> sb.Append("<br>");
> sb.Append(child.Name);
> }
> sb.Append("<hr>");
> sb.Append("<br>");
> sb.Append("<b>::Properties::</b><br>");
> foreach (string key in properties.PropertyNames)
> {
> foreach (object objProp in properties[key])
> {
> sb.Append("<br>");
> sb.Append(key.ToUpper() + "=" + Convert.ToString(objProp));
> }
> sb.Append("<br>");
> sb.Append("~~~");
> }
> }
>

date: Sun, 23 Oct 2005 17:01:40 +0800 author: Joe Kaplan \(MVP - ADSI\)

Re: Active Directory querying

Changing from "cn=<username>" to "sAMAccountName=<username>" is now
allowing me to see values for any of the domain's users.  Thanks for
your help thus far!

What initially made you suspect that that change would/could make the
difference?  What scenarios could cause the CN not to equal the
sAMAccountName?  Other than the previous two listed links, do you know
of any other useful sites on working with ADSI?  Any exra info you can
provide is greatly appreciated!

date: 24 Oct 2005 07:53:18 -0700 author: PTNL

Re: Active Directory querying

>What initially made you suspect that that change would/could make the
>difference?  What scenarios could cause the CN not to equal the
>sAMAccountName?  

The SAM Account Name is the pre-Win 2000 "user logon name" which is
limited to 20 chars and usually shouldn't contain any special chars
like spaces etc. So you have names like "JOHNDOE" or "JANEB" or stuff
like that - short and sweet, but hardly really readable.

A directory like LDAP/Active Directory is meant to be more "real",
e.g. deal with REAL names and people's names, so you will typically
have your user accounts called "John Doe", and "Jane Black" (and those
names will be the CN - the common-name - of the user accounts).

Thus you typically have a disconnect between the human-readable, real
user name like "John Doe", and his techie, Windows logon name like
"JOHND" or whatever.

Active Directory gives you a lot of "names" for a user - besides these
two, there are among others a "displayName" (which is intended to be
displayed to the user of an app), the "givenName" (first name) and
"sn" (surname - family name) parts of your name (plus "initials", of
course), and a few more. But those really are just for information -
sAMACcountName and CN are the ones that are real important, since they
identify a (user) account more than anything else.

Marc
________________________________________________________________
Marc Scheuner ** mscheuner -at- mvps.org ** http://adsi.mvps.org
Microsoft MVP for Directory Services Programming
  http://www.dirteam.com/blogs/mscheuner/default.aspx
  http://groups.yahoo.com/group/ADSIANDDirectoryServices/

date: Tue, 25 Oct 2005 07:37:20 +0200 author: Marc Scheuner [MVP ADSI]

Re: Active Directory querying

Marc basically sums it up.  The sAMAccountName is the attribute that 
represents the pre-win2k login name.  The CN (common name) is the attribute 
that identifies the object in the directory hierarchy.

You were using the login name to log in, so it appeared to me that you would 
also want to make sure your search was based on the login name as well.  It 
also helped that I've seen other people make the same mistake a few times 
before.  :)

There are many reasons why the might be different, but as a programmer, you 
really just know that they can be, so you need to assume they are in your 
code.  The only reason the two attributes are ever the same is by some sort 
of administrative convention, so if you make the assumption they are the 
same, your code will fail at whatever percentage the convention s not 
followed in your directory.  Luckily, the percentage was high enough so that 
you caught this before you got too far.

In the large directory where I work (140K+ users), we actually do make the 
sAMAccountName by convention in our automated processes, so they usually are 
the same (99.9% of the time).  However, a few exceptions still occur and 
code that assumes they are same breaks often enough to be annoying.

Joe K.

"Marc Scheuner [MVP ADSI]"  wrote in message 
news:dtgrl15cuatndjjrqk3i3pjn4ig0s8cse7@4ax.com...
> >What initially made you suspect that that change would/could make the
>>difference?  What scenarios could cause the CN not to equal the
>>sAMAccountName?
>
> The SAM Account Name is the pre-Win 2000 "user logon name" which is
> limited to 20 chars and usually shouldn't contain any special chars
> like spaces etc. So you have names like "JOHNDOE" or "JANEB" or stuff
> like that - short and sweet, but hardly really readable.
>
> A directory like LDAP/Active Directory is meant to be more "real",
> e.g. deal with REAL names and people's names, so you will typically
> have your user accounts called "John Doe", and "Jane Black" (and those
> names will be the CN - the common-name - of the user accounts).
>
> Thus you typically have a disconnect between the human-readable, real
> user name like "John Doe", and his techie, Windows logon name like
> "JOHND" or whatever.
>
> Active Directory gives you a lot of "names" for a user - besides these
> two, there are among others a "displayName" (which is intended to be
> displayed to the user of an app), the "givenName" (first name) and
> "sn" (surname - family name) parts of your name (plus "initials", of
> course), and a few more. But those really are just for information -
> sAMACcountName and CN are the ones that are real important, since they
> identify a (user) account more than anything else.
>
> Marc
> ________________________________________________________________
> Marc Scheuner ** mscheuner -at- mvps.org ** http://adsi.mvps.org
> Microsoft MVP for Directory Services Programming
>  http://www.dirteam.com/blogs/mscheuner/default.aspx
>  http://groups.yahoo.com/group/ADSIANDDirectoryServices/

date: Tue, 25 Oct 2005 21:53:30 +0800 author: Joe Kaplan \(MVP - ADSI\)