mscorlib [00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00] 1.0.5000.0 2.0.0.0 4.0.0.0 Gtk# is thread aware, but not thread safe; See the <link location="node:gtk-sharp/programming/threads">Gtk# Thread Programming</link> for details. System.Object System.Security.Principal.IPrincipal System.Runtime.InteropServices.ComVisible(true)

The class is primarily used to check the role of a Windows user. The method overloads let you check the user role by using different role contexts.

Enables code to check the Windows group membership of a Windows user.

- Constructor
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  To be added

  Initializes a new instance of the class by using the specified object.

  The object from which to construct the new instance of .
- Property
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Security.Principal.IIdentity The current identity of the principal. The returned identity will always be a instance.

  Gets the identity of the current principal.

- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Boolean ``

  When testing for newly created role information, such as a new user or a new group, it is important to log out and log in to force the propagation of role information within the domain. Not doing so can cause the test to return false. This method is not supported on Windows 98 or Windows Millennium Edition.

  For performance reasons, the overload is recommended as the preferable overload for determining the user's role.

  In Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. When you attempt to perform a task that requires administrative privileges, you can dynamically elevate your role by using the Consent dialog box. The code that executes the method does not display the Consent dialog box. The code returns false if you are in the standard user role, even if you are in the Built-in Administrators group. You can elevate your privileges before you execute the code by right-clicking the application icon and indicating that you want to run as an administrator.

  Relative identifiers (RIDs) are components of a Windows user group's security identifier (SID) and are supported to help prevent cross-platform localization issues. Many user accounts, local groups, and global groups have a default RID value that is constant across all versions of Windows.

  For example, the RID for the BUILTIN\Administrators role is 0x220. Using 0x220 as the input parameter for the method results in true being returned if the current principal is an administrator.

  The following tables list the default RID values.

  Built-in users

  RID

  DOMAINNAME\Administrator

  0x1F4

  DOMAINNAME\Guest

  0x1F5

  Built-in global groups

  RID

  DOMAINNAME\Domain Admins

  0x200

  DOMAINNAME\Domain Users

  0x201

  DOMAINNAME\Domain Guests

  0x202

  Built-in local groups

  RID

  BUILTIN\Administrators

  0x220

  BUILTIN\Users

  0x221

  BUILTIN\Guests

  0x222

  BUILTIN\Account Operators

  0x224

  BUILTIN\Server Operators

  0x225

  BUILTIN\Print Operators

  0x226

  BUILTIN\Backup Operators

  0x227

  BUILTIN\Replicator

  0x228

  Determines whether the current principal belongs to the Windows user group with the specified relative identifier (RID).

  true if the current principal is a member of the specified Windows user group, that is, in a particular role; otherwise, false.

  The RID of the Windows user group in which to check for the principal’s membership status.
- Method
  2.0.0.0
  4.0.0.0
  System.Runtime.InteropServices.ComVisible(false)
  System.Boolean ``

  The uniquely identifies a user or group on Windows 2000, Windows Server, and Windows XP implementations. When testing for newly created role information, such as a new user or a new group, it is important to log out and log in to force the propagation of role information within the domain. Not doing so can cause the test to return false. This method is not supported on Windows 98 or Windows Millennium Edition.

  In Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. When you attempt to perform a task that requires administrative privileges, you can dynamically elevate your role by using the Consent dialog box. The code that executes the method does not display the Consent dialog box. The code returns false if you are in the standard user role, even if you are in the Built-in Administrators group. You can elevate your privileges before you execute the code by right-clicking the application icon and indicating that you want to run as an administrator.

  For performance reasons, this is the preferable overload to determine a user's role.

  Determines whether the current principal belongs to the Windows user group with the specified security identifier (SID).

  true if the current principal is a member of the specified Windows user group; otherwise, false.

  A that uniquely identifies a Windows user group.
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Boolean ``

  When testing for newly created role information, such as a new user or a new group, it is important to log out and log in to force the propagation of role information within the domain. Not doing so can cause the test to return false. This method is not supported on Windows 98 or Windows Millennium Edition.

  For performance reasons, the overload is recommended as the preferable overload for determining the user's role.

  In Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. When you attempt to perform a task that requires administrative privileges, you can dynamically elevate your role by using the Consent dialog box. The code that executes the method does not display the Consent dialog box. The code returns false if you are in the standard user role, even if you are in the Built-in Administrators group. You can elevate your privileges before you execute the code by right-clicking the application icon and indicating that you want to run as an administrator.

  Determines whether the current principal belongs to the Windows user group with the specified .

  true if the current principal is a member of the specified Windows user group; otherwise, false.

  One of the values.
- Method
  1.0.5000.0
  2.0.0.0
  4.0.0.0
  System.Boolean ``

  When testing for newly created role information, such as a new user or a new group, it is important to log out and log in to force the propagation of role information within the domain. Not doing so can cause the test to return false. This method is not supported on Windows 98 or Windows Millennium Edition.

  For performance reasons, the overload is recommended as the preferable overload for determining the user's role.

  In Windows Vista, User Account Control (UAC) determines the privileges of a user. If you are a member of the Built-in Administrators group, you are assigned two run-time access tokens: a standard user access token and an administrator access token. By default, you are in the standard user role. When you attempt to perform a task that requires administrative privileges, you can dynamically elevate your role by using the Consent dialog box. The code that executes the method does not display the Consent dialog box. The code returns false if you are in the standard user role, even if you are in the Built-in Administrators group. You can elevate your privileges before you execute the code by right-clicking the application icon and indicating that you want to run as an administrator.

  For built-in roles, the string should be in the form "BUILTIN\RoleNameHere". For example, to test for membership in the Windows administrator role, the string representing the role should be "BUILTIN\Administrators". Note that the backslash might need to be escaped. The following table lists the built-in roles.

  The spelling for the BUILTIN roles in string format differs from the spelling used in the enumeration. For example, the spelling for an administrator in the enumeration is "Administrator", not "Administrators". When using this overload, use the spelling for the role from the following table.

  Built-in local groups

  BUILTIN\Administrators

  BUILTIN\Users

  BUILTIN\Guests

  BUILTIN\Account Operators

  BUILTIN\Server Operators

  BUILTIN\Print Operators

  BUILTIN\Backup Operators

  BUILTIN\Replicator

  For machine-specific roles, the string should be in the form "MachineName\RoleNameHere".

  For domain-specific roles, the string should be in the form "DomainName\RoleNameHere"; for example, "SomeDomain\Domain Users".

  In the .NET Framework version 1.0, the parameter is case-sensitive. In the .NET Framework version 1.1 and later, the parameter is case-insensitive.

  Determines whether the current principal belongs to the Windows user group with the specified name.

  true if the current principal is a member of the specified Windows user group; otherwise, false.

  The name of the Windows user group for which to check membership.