DirectoryEntry.Invoke access is denied

[Jason]

In an ASP.NET application designed as intranet using Windows Authentication.

I am trying to query a PDC group to see if a string matches a user that is
assigned to the group using the function below. On my development box, all is
ok when I access through debug or using the http://localhost. When I access
this on the deployment server 2003 or on my dev box using the
http://ipaddress I get an
access is denied on the line:
object oRet = de.Invoke("Members") .

What changes to security do I need to apply? I have an NT group that
limits all the users that can run this.

TIA, Jason

private bool UserIdExistsInNT4Group()
{
DirectoryEntry de = new DirectoryEntry();
de.Path = @"WinNT://wfdcptnt1/CMStest,group";
object oRet = de.Invoke("Members");
IEnumerable users = (IEnumerable) oRet;
foreach(object user in users)
{
DirectoryEntry det = new DirectoryEntry(user);
string tuserid = det.Path;
tuserid = tuserid.Replace("WinNT://", "");
tuserid = tuserid.Replace("/", "\\");
_log.Debug(tuserid);
if (tuserid.ToUpper() == this.UserId.ToUpper())
{
return true;
}
}
return false;
}

 

[Joe Kaplan \(MVP - ADSI\)]

Why not just use Context.User.IsInRole("domain\group name")?

It is a lot easier than trying to get your delegation scenario working and
much easier than trying to enumerated the users groups (which is much much
more complex than the code you show below).

Joe K.

 

[Jason]

Well, eventually they are going to ask me to put all the users in a listbox
instead
of making them type it in.

 

[Jason]

actually, this wont work.

Scenario is User A is trying to modify a database record
which has a field which is a userid. This userid is another
staff's user id and the business rule says to ensure that
the user id typed in here is in the group. I wont be able
to create a staff B as a user running under staff A security
context.

 

[Joe Kaplan \(MVP - ADSI\)]

Ok, that makes more sense. I have a couple of questions for you:
- Are you using Active Directory, an NT4 domain or local machine groups?
- Is your AD domain 2003 native mode?
- Is your server Windows 2003?

My sense is that you should really be using the AzMan APIs to be doing what
you are trying to do. Trying to calculate group membership using Directory
Services calls is hard and it is much easier to let Windows do this for you.
There are quite a few options though:
- If you have 2003 AD and 2003 server to run on, you can use the "S4U"
constructor for WindowsIdentity to create a WindowsIdentity for an arbitary
user. From it, you can create a WindowsPrincipal and call IsInRole on that.
This is very easy and will be reasonably fast if you do some caching.
- Another option is to use the AzMan APIs to create an AzMan context for
the user and perform authorizations against it. I can't comment on
performance here.
- If you have AD, you can do a better job looking up groups using LDAP and
the tokenGroups constructed attribute. TokenGroups calculates fully nested
group membership and includes the primary group, which you may need. It
also does not include distribution groups (which Members will).

If you do have AD, I would suggest staying far away from the WinNT provider
for ADSI/S.DS, especially in ASP.NET scenarios (partly for the problems you
are having now; they are easier to overcome with LDAP).

Joe K.

 

[Jason]

Yeah, having to hit NT4 Domain and we are planning to go to AD but was told
we were not going to use the Kerberos authentication provider. This app is
running on a Windows2003 server.

Is this a code snippet like you are describing? If having Server2003 and
AD2003.

WindowsIdentity wi = new WindowsIdentity(this._userId);
WindowsPrincipal wp = new WindowsPrincipal(wi);
return wp.IsInRole(@"DOMAIN\Test");

 

[Joe Kaplan \(MVP - ADSI\)]

Yes, that code snippet works great if you are running on 2K3 server and have
2K3 native AD. It would not work if there is no Kerberos in the environment
as it is a Kerberos feature that allows you to create the WindowsIdentity
from the UPN. However, I find it hard to imagine that you won't be using
Kerberos once you move to AD as it is the native authentication protocol for
AD and Win2K+. There is no reason why you would want to avoid it that I'm
aware of and many reasons why you will want or need it.

Best of luck,

Joe K.