Impersonation Level for MBAM

Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today, I am going to solve one of the rare errors that can occur while implementing MBAM infrastructure.

My customer had a problem while accessing both MBAM websites: helpdesk portal and self-service portal. Opening any of them resulted in displaying only text version of the webpage without any graphical user interface:

(Sometimes entire webpage was not loading and showing HTTP error 500.)

When we looked at the details in Fiddler and in Developers panel of Internet Explorer it appeared that all elements except index.html were getting status code 500 – Internal Server Error.

HTTP status code 500 is very general (it means something on the server side went wrong but we don’t know yet what) so decided to install and enable “Failed Request Tracing in IIS” and then reproduced the error.

Logs by default are stored in %SystemDrive%\inetpub\logs\FailedReqLogFiles.

Our logs indicated clearly that there was a problem with impersonation of the account logging to the portal. (0x80070542)

The problem was that customer applied GPO security hardening to their servers which removed IIS_IUSRS group from the “Impersonate a client after authentication” setting (internal name SeImpersonatePrivilege).

This policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created to impersonate that client. (Such an action could elevate the unauthorized user's permissions to administrative or system levels.)

Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client/server applications. When running in a client's security context, a service "is" the client, to some degree. One of the service's threads uses an access token representing the client's credentials to obtain access to the objects to which the client has access. The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded, depending on what the client has permission to do.

Services that are started by the Service Control Manager have the built-in Service group added by default to their access tokens. COM servers that are started by the COM infrastructure and configured to run under a specific account also have the Service group added to their access tokens. As a result, these processes are assigned this user right when they are started.

IUSRS is a local, empty group that is populated automatically when IIS application pool starts. For example, all the build in AppPoolAccounts and custom accounts used to run the IIS application pools are added there when they start.

Below you can see that my IIS_IUSRS group is empty

but account used to run application pool “contoso\mbam_iis” has that group in its Windows token:

Summary: In order to resolve the issue, add IIS_IUSRS group to “Impersonate a client after authentication” user right assignment.

And enjoy browsing fixed MBAM portals:

Rafal