Scenario: Using Authorization Manager with Custom Principals

  • Article

Applies To: Windows Server 2003 with SP1

Applications that use custom or non-Windows principals (for example, SQL, Passport, Microsoft Commerce Server, or ADAM principals) can leverage most of Authorization Manager's runtime features.

Whether in Active Directory or in XML, Authorization Manager will store SIDs as members of groups and roles, except for LDAP query groups, which don't have static members. When a SID is added to a role or an application group, it is not verified as a SID corresponding to an Active Directory or Windows NT account. You can add a completely meaningless SID as a member of a role or a group. When IAzClientContext::AccessCheck is called, the SIDs in the client context are compared to SIDs in Authorization Manager roles and groups and there is no validation of the SID as an Active Directory account. If a client context has a custom SID and a role has the same custom SID assigned to iteither directly or by way of an application group that has the same custom SIDthe AccessCheck function will check if the SID is a member of a role or group with the requested operation and grant the permissions associated with the roles to which the SID is assigned. You can use this behavior to add custom principal types to roles or application basic groups in Authorization Manager by creating a custom SID for each custom principal and assigning that SID to appropriate roles and application basic groups

Textual SIDs have the structure S-Version-AuthorityID-X-Y-Z, where Version is the SID version number, AuthorityID is the security authority ID of the issuer of the SID, and X, Y and Z are sub-authority values. (Currently, all SIDs are version 1.) SIDs are variable in length because then number of subauthorites in SIDs can vary. SIDs can have up to SID_MAX_SUB_AUTHORITIES sub-authorities. (This is defined as 15 in winnt.h.) Custom SIDs use 1 for the version number, the SECURITY_RESOURCE_MANAGER_AUTHORITY for the AuthorityID value, and custom values for sub-authorities.

When creating custom SIDs you must establish a SID design for your application. For example, you might have S-1-9-AppInstanceGUID-UserGuid, where 9 is the resource manager subauthority and AppInstanceGUID and UserGUID are each broken into four sub authorities. You can also use S-1-9-AppInstanceGuid-UserRID, where UserRID is a unique number for the user in the scope of the application instance. For sample code that generates a GUID, see the Microsoft Windows Software Development Kit (SDK).

Once you have created a custom SID, you can add the SID to Authorization Manager roles or groups using the AddMember method of the IAzRole or IAzApplicationGroup interfaces.

To initialize a client context with a custom SID, you can call IAzApplication::InitializeClientContextFromSID and specify a custom SID in string form. This creates a valid client context that is suitable for performing access validation for the custom principal. In practice, after a custom principal authenticates, an application maps the authenticated principal to a custom SID that is previously created for the principal and calls InitializeClientContextFromSID to attain a Authorization Manager client context. When AccessCheck is called on this client context, this SID will be evaluated for membership in Authorization Manager roles and groups.

Drawbacks to custom principals

There are some drawbacks to using custom principals.

  • You cannot use LDAP query groups. Since the user is not in Active Directory, it does not make sense to have LDAP query groups.

  • You cannot use Active Directory groups or local machine groups.

  • You cannot use the Authorization Manager MMC user interface. Since the user interface validates user SIDs when displaying role or group memberships, administrators see textual string SIDs in the user interface and not user names. More importantly, the user interface only obtains SIDs to enter into roles and application groups by way of Object Picker, which only allows you to pick valid accounts or groups.

Using custom principals

The following figure illustrates the process of authorizing custom principals.

Figure 8: Authorizing custom principals

Art Image

  1. Authenticate the custom principal user. and then map the custom principal to an Authorization Manager custom SID.

  2. Use InitializeClientContextFromSID and pass the AZ_CLIENT_CONTEXT_SKIP_GROUP flag as the loptions parameter to build a client context with the custom SID.

After this is done, you can use AccessCheck to verify that the custom principal is authorized to perform the specified operations in the specified scope.