Check group membership, the sequel

[Sameh Ahmed]

Hello there
IsInrole gives ya the means to check if the current or impersonated user
belongs to a specific windows role or group.
is there a way to do the same without using ADSI to check if "domain\user"
belongs to "domain\group"?
the reason is, when getting the "memberof" property of a user, then checking
if it contains the desired group or not.
this will only work if the user is a member of the group itself but not when
he is a member of a group that belongs to the designated group.
Do I make sense?
Regards
Sameh

[Joe Kaplan \(MVP - ADSI\)]

I still think you should be using WindowsPrincipal::IsInRole. What happened
when you tried the reflection code I suggested?

It is possible to do group membership expansion programmatically, but it
seems like it would be better to try and get the built in stuff that already
supports this working.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...

Hello there
IsInrole gives ya the means to check if the current or impersonated user
belongs to a specific windows role or group.
is there a way to do the same without using ADSI to check if "domain\user"
belongs to "domain\group"?
the reason is, when getting the "memberof" property of a user, then
checking if it contains the desired group or not.
this will only work if the user is a member of the group itself but not
when he is a member of a group that belongs to the designated group.
Do I make sense?
Regards
Sameh

[Sameh Ahmed]

The code you sent worked very good.
and in a domain environment the isinrole worked also very well.
I use it to make the decision if the current user (running the application)
has the right to be using it or the application should quit.
So for this part, it was solved and everything work in a very good way.
within the functionality of the application, I need to take a decision on
how to handle users depending on their group memberships, IE if the
"domain\user" belongs to the group "domain\group" it should be dealt with in
the manner A, and if it belongs to the "domain\another group" it should be
handled in the manner B.
do I need to check if the user belongs to a certain group or not (explicitly
or implicitly by belonging to a group that is a member of the
"domain\group")
Hope I made myself clear on that one.
thanks again.
Regards
Sameh
"Joe Kaplan (MVP - ADSI)" <jo*************@removethis.accenture.com> wrote
in message news:%2******************@tk2msftngp13.phx.gbl...

I still think you should be using WindowsPrincipal::IsInRole. What
happened when you tried the reflection code I suggested?

It is possible to do group membership expansion programmatically, but it
seems like it would be better to try and get the built in stuff that
already supports this working.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...

Hello there
IsInrole gives ya the means to check if the current or impersonated user
belongs to a specific windows role or group.
is there a way to do the same without using ADSI to check if
"domain\user" belongs to "domain\group"?
the reason is, when getting the "memberof" property of a user, then
checking if it contains the desired group or not.
this will only work if the user is a member of the group itself but not
when he is a member of a group that belongs to the designated group.
Do I make sense?
Regards
Sameh

[Joe Kaplan \(MVP - ADSI\)]

IsInRole supports fully nested security group membership (assuming you are
on a 2000 native AD domain that supports nested groups). You don't have to
do anything extra to make this work.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

The code you sent worked very good.
and in a domain environment the isinrole worked also very well.
I use it to make the decision if the current user (running the
application) has the right to be using it or the application should quit.
So for this part, it was solved and everything work in a very good way.
within the functionality of the application, I need to take a decision on
how to handle users depending on their group memberships, IE if the
"domain\user" belongs to the group "domain\group" it should be dealt with
in the manner A, and if it belongs to the "domain\another group" it should
be handled in the manner B.
do I need to check if the user belongs to a certain group or not
(explicitly or implicitly by belonging to a group that is a member of the
"domain\group")
Hope I made myself clear on that one.
thanks again.
Regards
Sameh
"Joe Kaplan (MVP - ADSI)" <jo*************@removethis.accenture.com> wrote
in message news:%2******************@tk2msftngp13.phx.gbl...

I still think you should be using WindowsPrincipal::IsInRole. What
happened when you tried the reflection code I suggested?

It is possible to do group membership expansion programmatically, but it
seems like it would be better to try and get the built in stuff that
already supports this working.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...

Hello there
IsInrole gives ya the means to check if the current or impersonated user
belongs to a specific windows role or group.
is there a way to do the same without using ADSI to check if
"domain\user" belongs to "domain\group"?
the reason is, when getting the "memberof" property of a user, then
checking if it contains the desired group or not.
this will only work if the user is a member of the group itself but not
when he is a member of a group that belongs to the designated group.
Do I make sense?
Regards
Sameh

[Sameh Ahmed]

I need to specify a different use the one used to run the code

"Joe Kaplan (MVP - ADSI)" <jo*************@removethis.accenture.com> wrote
in message news:u1**************@tk2msftngp13.phx.gbl...

IsInRole supports fully nested security group membership (assuming you are
on a 2000 native AD domain that supports nested groups). You don't have
to do anything extra to make this work.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:%2******************@TK2MSFTNGP10.phx.gbl...

The code you sent worked very good.
and in a domain environment the isinrole worked also very well.
I use it to make the decision if the current user (running the
application) has the right to be using it or the application should quit.
So for this part, it was solved and everything work in a very good way.
within the functionality of the application, I need to take a decision on
how to handle users depending on their group memberships, IE if the
"domain\user" belongs to the group "domain\group" it should be dealt with
in the manner A, and if it belongs to the "domain\another group" it
should be handled in the manner B.
do I need to check if the user belongs to a certain group or not
(explicitly or implicitly by belonging to a group that is a member of the
"domain\group")
Hope I made myself clear on that one.
thanks again.
Regards
Sameh
"Joe Kaplan (MVP - ADSI)" <jo*************@removethis.accenture.com>
wrote in message news:%2******************@tk2msftngp13.phx.gbl...

I still think you should be using WindowsPrincipal::IsInRole. What
happened when you tried the reflection code I suggested?

It is possible to do group membership expansion programmatically, but it
seems like it would be better to try and get the built in stuff that
already supports this working.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:Oy**************@TK2MSFTNGP09.phx.gbl...
Hello there
IsInrole gives ya the means to check if the current or impersonated
user belongs to a specific windows role or group.
is there a way to do the same without using ADSI to check if
"domain\user" belongs to "domain\group"?
the reason is, when getting the "memberof" property of a user, then
checking if it contains the desired group or not.
this will only work if the user is a member of the group itself but not
when he is a member of a group that belongs to the designated group.
Do I make sense?
Regards
Sameh

[Joe Kaplan \(MVP - ADSI\)]

So, you need to look up the group membership for a user that you don't have
a security token for? That is a little bit harder.

The absolute best way to deal with that situation is to use the protocol
transition (S4U) feature of Windows Server 2003 AD by creating a
WindowsIdentity for the use with their userPrincipalName. You don't need a
password for this. You get a lower privileged token, but you can still
create a WindowsPrincipal that can be used for role checks.

If you don't have a native mode 2003 AD, then this problem is harder to deal
with. You'll probably need to do some directory services code to do the
group membership expansion (although the AzMan APIs may be an option as
well). The secret with LDAP calls is to use the tokenGroups attribute which
is a calculated attribute that contains the fully expanded security group
membership for the object.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:uo**************@TK2MSFTNGP10.phx.gbl...

I need to specify a different use the one used to run the code

"Joe Kaplan (MVP - ADSI)" <jo*************@removethis.accenture.com> wrote
in message news:u1**************@tk2msftngp13.phx.gbl...

IsInRole supports fully nested security group membership (assuming you
are on a 2000 native AD domain that supports nested groups). You don't
have to do anything extra to make this work.

Joe K.

[Sameh Ahmed]

unfortunately this is a 2000 Domain.
and tokenGroups on rarely mentioned on the MSDN, I will keep searching till
I get something useful on how to use that attribute.
Regards
Thanks Joe
"Joe Kaplan (MVP - ADSI)" <jo*************@removethis.accenture.com> wrote
in message news:O7**************@tk2msftngp13.phx.gbl...

So, you need to look up the group membership for a user that you don't
have a security token for? That is a little bit harder.

The absolute best way to deal with that situation is to use the protocol
transition (S4U) feature of Windows Server 2003 AD by creating a
WindowsIdentity for the use with their userPrincipalName. You don't need
a password for this. You get a lower privileged token, but you can still
create a WindowsPrincipal that can be used for role checks.

If you don't have a native mode 2003 AD, then this problem is harder to
deal with. You'll probably need to do some directory services code to do
the group membership expansion (although the AzMan APIs may be an option
as well). The secret with LDAP calls is to use the tokenGroups attribute
which is a calculated attribute that contains the fully expanded security
group membership for the object.

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:uo**************@TK2MSFTNGP10.phx.gbl...

I need to specify a different use the one used to run the code

"Joe Kaplan (MVP - ADSI)" <jo*************@removethis.accenture.com>
wrote in message news:u1**************@tk2msftngp13.phx.gbl...

IsInRole supports fully nested security group membership (assuming you
are on a 2000 native AD domain that supports nested groups). You don't
have to do anything extra to make this work.

Joe K.

[Joe Kaplan \(MVP - ADSI\)]

Here's a link to one S.DS sample I've posted. Google should turn up more
hits:

http://groups.google.com/groups?hl=e...TNGP12.phx.gbl

Joe K.

"Sameh Ahmed" <es******@hotmail.com> wrote in message
news:es****************@TK2MSFTNGP09.phx.gbl...

unfortunately this is a 2000 Domain.
and tokenGroups on rarely mentioned on the MSDN, I will keep searching
till I get something useful on how to use that attribute.
Regards
Thanks Joe