IsinRole function only works with built-in roles

B

Bob

This a bit of a second post on same subject, my apologies.

IsinRole function only works with built-in roles. If I create a new group on
my domain controller then add an existing user to that group, user bob,
group TestUsers and then try to determine if My.user.Isinrole("TestUsers") I
always get a false, which is incorrect.
If I put Bob as part of Administrators or any other built-in group on the DC
and look at My.User.isinrole("Administrators") I get true, which is correct

Is this a bug? I need to determine if my application's user is part of a
group I created on my domain controller. If I can't use isinrole to do that,
how can I do that? I've looked at the walkthrough for custom authentication
but that's not what I need to do. I simply need to be able to see if my user
is in a group I created on the domain controller.

Any help would be appreciated.

Bob
 
B

Bob

Additional Info:
I also looked at whoami /groups on my workstation and I notice that the
custom groups that User Bob belongs to do not appear in the list. I see 15
user groups. One custom one I created on the local machine, but none that
have been created on the DC.

I tested the Isinrole on the Customone on the local machine by specifying
the domain name and the local group in the isinrole and that works fine.

So the question becomes, why does my custom groups that bob is a member do
not get detected by whoami and by the system procedures that isinrole uses?
Sorry can't put it another way?

Any help again greatly appreciated.

Bob
 
S

Scott M

Bob, I know that on our domain here at work we have to reboot our machine to
pick up the new definition from the DC. Have you tried that?
 
P

Peter Huang [MSFT]

Hi Bob,

Also you may simply logoff and relogon to the machine to see if that works
for you.
Whoami tool is a good tool to check your group membership list.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
B

Bob

Hi Peter, after I had posted I had read your reply to an eaelier question
regrading the same subject. and I had tried to reboot the local machine and
used whoami before and after the reboot , results were the same. The custom
groups that I created on the server do not appear on the workstation. I then
got one of those haha moments and checked with whoami on the server itself
for the same user and look and behold. The custom groups do not appear in
the users list when executing whoami. I then rebooted the DC SERVER and
again look and behold, the custom groups now appear in the server when
executing whoami. If this is the way it supposed to work its pretty
ridiculous. We can't have users being forced to reboot their domain servers
every time a new group is created so that networked users can have acccess
to it. But from what I've seen this is the way it works <GGGG>
I will keep you further informed of any findings on this subject.
If this is indeed the way it works please confirm that to me, maybe there is
a service that needs to be activated on the server and workstations to
correct this behaviour. If there is not, please pass this one on to the
development team and see if they can't get some patch out to correct this
behaviour. Can you imagine a company with 10 or so servers and a few hundred
workstations doing critical work night and day saying, hey we just created a
new department for users, everybody shutdown for 15 minutes please.
Ridiculous! And by the way, even though W2003 might not have the problem, (I
haven't had time to check) its important to patch w2k servers. And please
don't use this as a way of selling upgrades - I know I'm cynical, sorry ;-),
been there saw it.

But I realy DO appreciate your input, it was very helpfull

Thanks
Bob
 
B

Bob

Additional check. After I checked the DC and saw the new roles for the user.
I checked the client computer before rebooting. The new roles were not
there. I had to reboot the client also! RIDICULOUS!
There's got to be a way to prevent the reboot requirement. That behaviour
just makes absolutely no sense.

Regards,

Bob
 
G

Guest

I've been having slightly different problems with isinrole. It seems to work
for global security groups in the AD, but local security groups are not
working.

Does IsInRole work on AD Domain-Local security groups?

Rob
 
B

Bob

I'm not sure, But here's what I tested.
I created a new user group on my local Winmdows XP pro Box and since that
box is part of a domain I added a domain user to that local group. Then I
had to reboot the local box. After that when I logged in as the domain user
and wrote in my code
My.user.isinrole("MylocalBoxName\MyUserName") I got back True (BTW not sure
if it was slash or backslash)

I don't know if this is any help to you but in any case,
Happy new year.!
Bob
 
P

Peter Huang [MSFT]

Hi

Based on research, I think it is possbile that there are more than one AD
server, so the information is not replicated in time. Maybe your client is
contacting an AD server which is not the one you make change.

Also you may try to run the Gpupdate tool on the client machine.
Gpupdate
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-
us/refrgp.mspx

Since this newsgroup is mainly for dev issue, for detailed information
about AD operating, please try to post in the newsgroup below.
microsoft.public.win2000.active_directory
microsoft.public.windows.server.active_directory

Thanks for your understanding!

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
J

Jay B. Harlow [MVP - Outlook]

Bob,
According to the following:

http://msdn.microsoft.com/library/d...ncipalwindowsprincipalclassisinroletopic2.asp

You need to qualify the name with the domain. However it I don't see it
working.

Given the following code:

My.User.InitializeWithWindowsUser()
Debug.WriteLine(My.User.IsInRole("VS Developers"), "VS Developers")
Debug.WriteLine(My.User.IsInRole("MYDOMAIN\VS Developers"),
"MYDOMAIN\VS Developers")

Debug.WriteLine(My.User.IsInRole("mydomain.local\VS Developers"),
"mydomain.local\VS Developers")

Debug.WriteLine(My.User.IsInRole("MYMACHINE\VS Developers"),
"MYMACHINE\VS Developers")

Where VS Developers is a group at both the domain level & the local level.
My domain account is a member of both groups

I get the following output:

VS Developers: True
MYDOMAIN\VS Developers: False
mydomain.local\VS Developers: False
MYMACHINE\VS Developers: True

Which suggests to me that I local groups (machine) work, while domain groups
don't. Although I may have the syntax wrong or setup wrong.

I just tried "mydomain.local\Schema Admins" and it succeeded, the only
difference between Schema Admins & VS Developers is that the former is a
Global group, while the later is a Domain Local group. I'll try changing VS
Developers to a Global group also...

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| This a bit of a second post on same subject, my apologies.
|
| IsinRole function only works with built-in roles. If I create a new group
on
| my domain controller then add an existing user to that group, user bob,
| group TestUsers and then try to determine if My.user.Isinrole("TestUsers")
I
| always get a false, which is incorrect.
| If I put Bob as part of Administrators or any other built-in group on the
DC
| and look at My.User.isinrole("Administrators") I get true, which is
correct
|
| Is this a bug? I need to determine if my application's user is part of a
| group I created on my domain controller. If I can't use isinrole to do
that,
| how can I do that? I've looked at the walkthrough for custom
authentication
| but that's not what I need to do. I simply need to be able to see if my
user
| is in a group I created on the domain controller.
|
| Any help would be appreciated.
|
| Bob
|
|
 
J

Jay B. Harlow [MVP - Outlook]

Additional.

1) It appears that local groups will hide/shadow domain groups.

2) It appears that unqualified names are local groups only:

My.User.IsInRole("VS Developers") ' checks local groups only

3) Does not check Domain Local groups, needs to be a Global group in AD.



FWIW: In VS 2005 (.NET 2.0) you can use the Groups property of
WindowsIdentity to get the list of groups that Identity belongs to:

My.User.InitializeWithWindowsUser()
Dim identity As System.Security.Principal.WindowsIdentity =
TryCast(My.User.CurrentPrincipal.Identity,
System.Security.Principal.WindowsIdentity)

For Each group As System.Security.Principal.SecurityIdentifier In
identity.Groups
Debug.WriteLine(group.Translate(GetType(System.Security.Principal.NTAccount)),
"group")
Next

http://msdn2.microsoft.com/en-us/library/system.security.principal.windowsidentity.groups.aspx

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


message | Bob,
| According to the following:
|
|
http://msdn.microsoft.com/library/d...ncipalwindowsprincipalclassisinroletopic2.asp
|
| You need to qualify the name with the domain. However it I don't see it
| working.
|
| Given the following code:
|
| My.User.InitializeWithWindowsUser()
| Debug.WriteLine(My.User.IsInRole("VS Developers"), "VS Developers")
| Debug.WriteLine(My.User.IsInRole("MYDOMAIN\VS Developers"),
| "MYDOMAIN\VS Developers")
|
| Debug.WriteLine(My.User.IsInRole("mydomain.local\VS Developers"),
| "mydomain.local\VS Developers")
|
| Debug.WriteLine(My.User.IsInRole("MYMACHINE\VS Developers"),
| "MYMACHINE\VS Developers")
|
| Where VS Developers is a group at both the domain level & the local level.
| My domain account is a member of both groups
|
| I get the following output:
|
| VS Developers: True
| MYDOMAIN\VS Developers: False
| mydomain.local\VS Developers: False
| MYMACHINE\VS Developers: True
|
| Which suggests to me that I local groups (machine) work, while domain
groups
| don't. Although I may have the syntax wrong or setup wrong.
|
| I just tried "mydomain.local\Schema Admins" and it succeeded, the only
| difference between Schema Admins & VS Developers is that the former is a
| Global group, while the later is a Domain Local group. I'll try changing
VS
| Developers to a Global group also...
|
| --
| Hope this helps
| Jay [MVP - Outlook]
| .NET Application Architect, Enthusiast, & Evangelist
| T.S. Bradley - http://www.tsbradley.net
|
|
| || This a bit of a second post on same subject, my apologies.
||
|| IsinRole function only works with built-in roles. If I create a new group
| on
|| my domain controller then add an existing user to that group, user bob,
|| group TestUsers and then try to determine if
My.user.Isinrole("TestUsers")
| I
|| always get a false, which is incorrect.
|| If I put Bob as part of Administrators or any other built-in group on the
| DC
|| and look at My.User.isinrole("Administrators") I get true, which is
| correct
||
|| Is this a bug? I need to determine if my application's user is part of a
|| group I created on my domain controller. If I can't use isinrole to do
| that,
|| how can I do that? I've looked at the walkthrough for custom
| authentication
|| but that's not what I need to do. I simply need to be able to see if my
| user
|| is in a group I created on the domain controller.
||
|| Any help would be appreciated.
||
|| Bob
||
||
|
|
|
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top