Web Applications Authorization Risk When Using Windows Accounts

The use of Windows accounts to authorize users to applications introduces risk that an auditor should evaluate. Using Windows accounts to authorize users is very efficient as applications can utilize Windows’ strong password controls. The account authorization is usually simple. The application administrator only needs to create an account inside the application database that matches the user account in Windows, and the application logic checks the Windows account against the list of authorized accounts. By doing this, the application does not need custom coding to store and encrypt passwords. Users also prefer applications that use Windows authorization as they do not need to enter and remember additional passwords.

Some of the applications that use Windows accounts to authorize access are web-based applications. The Windows account works as a single sign-on (SSO) when the application uses the Windows account to check authorization.

Although Windows provides strong user and password controls, other risk is associated with using this methodology. This risk will be discussed in greater detail throughout this article. Some of the risk comes from applications’ administration relying on the Windows account administration as the main control to remove access to their application. Another risk comes from users with local administration rights to desktops who can create additional accounts on their devices.

When Windows accounts are used to authorize users in applications, the authorization check occurs by matching an account in the application database to the Windows account. Figure 1 explains this process.

An error the auditor could make is to mark the test as “OK” without further investigation. This assumption rationalizes that Windows authorization is strong and/or is tested somewhere else and might not need further testing. However, there are risk factors and controls that need to be evaluated to ensure that the application authorization that is using Windows accounts is working as expected. One of the main sources of risk stems from when the application completes the authorization check. The account authorization check could happen in two different ways:

1. Desktop authorization check—In this authorization check, the application verifies only that the account is active on the user desktop. This is shown in figure 2.
2. Server authorization check—In this authorization check, the application checks authorization against the Windows Active Directory server. This can be seen in figure 3.

One of the main reasons to use a desktop authorization check is to improve performance. It is faster to validate the account against the local Windows account instead of using the Active Directory server. However, a server authorization check is stronger, as it validates that the user account was used to sign on to the network. The following sections will discuss significant areas of risk associated with using windows authorization.

Validating Applications Accounts to the Desktop Cache Account

The first risk comes from breaking into the application by creating a local Windows account on the user’s computer. This is shown in figure 4.

This risk can be offset by implementing a control that allows the web-based application to verify that the user account was authorized by the Windows Active Directory server.

The most important control for using Windows authorization is to match the application account to the Active Directory server. By doing this, the application ensures that the account is a valid network account.

The other option that developers sometimes use is having the application verify that the account exists on the end-user’s computer (desktop authorization check). This option is sometimes used for performance reasons. However, using the local computer account for authorization has a higher risk of breaking into the applications, as users can often create local Windows accounts on their desktops but cannot usually create accounts in the Active Directory server.

Allowing Employees to Have Local Administration Rights

The second risk is allowing local computer administration rights to employees. This is offset by implementing a control that does not allow local administration rights.

This control is necessary to avoid risk to the organization. For this scenario, it means that anyone in the organization can create another employee’s Windows account on their computer, in turn gaining access to other employees’ transactions. This risk is also avoided if the control for the first risk works properly.

Allowing External Devices to Connect to the Network

The third risk is that external devices can connect to the network. This is shown in figure 5.

This risk is offset by implementing a control that allows only authorized computers to connect to the network.

This control is necessary to avoid risk to the organization. Many organizations do not have this control due to the complication of validating each computer that connects to the network. For this scenario, it means that anyone who can connect a personal device to the network may obtain access to the application. Intruders can create a local Windows account on their personal device that is the same as the one in use by the application. This is similar to the second risk, but uses external devices. This will allow the intruder to gain access to the application if the control for the first risk does not work properly.

Not Removing Application Accounts of Terminated Employees

The fourth risk is that new employees might gain access from terminated employees. This risk can be seen in figure 6.

This risk is offset by implementing a control to ensure application accounts are removed when employees leave the organization.

One problem when using Windows authorization for applications is that administrators do not remove the accounts of ex-employees when they leave the organization. This is because they rely on the removal of the Windows account as the main control to remove access. Although this is correct in principle, it introduces a new risk. The risk is a result of Windows accounts being recycled into the Active Directory.

Conclusion

User authentication is one of the most important controls that IT auditors should test. Understanding user authentication is important to address organizational risk and test it appropriately. This article explains in some detail the risk related to using Windows authentication. In particular, it explores the risk of having intruders emulate the accounts of existing users and the controls that should be implemented to avoid this risk. When organizations use Windows accounts to grant access to other applications, additional controls are needed to reduce the risk of having unauthorized access to applications and data. Some of the controls needed to mitigate this risk include verifying that the user account is logged to the network, removing local administrator rights of employees, validating devices that connect to the network and removing accounts of terminated employees.