Whether willing or not, not every company can completely remove the (most) sense of existence of domain control in the office system like Google. Domain is still a subtle existence for security personnel. On the one hand, the visual configuration of various domain strategies and accounts facilitates the IT desktop support personnel of most enterprises to do brainless configuration in the initial stage, but on the other hand, domain control is inherently incompatible with the new era zerotrust concept. The biggest slot is not that the authentication source is only available with fixed password (it is said that the new windows server will finally be introduced into OTP, and azure ad is supported to some extent). In addition, various management functions provided by other domains are also out of place under the large technology stack customized by Linux + open source components of modern Internet enterprises.

However, under the guidance of zerotrust concept, we can still strengthen and transform the windows authentication system, greatly improving its security. This series of articles will introduce various tools that may be used as well as mitigations provided by Microsoft itself, and then discuss how to build defense in depth based on these tools and concepts. After mentioning the inherent defects of windows password authentication, we will naturally ask the following questions: how to transform the inherent static domain authentication system? Under the guidance of this concept, what measures can be taken?

An obvious systematic transformation is to transform the authentication source directly through the access capability provided by the windows credential provider, replacing the original authentication capability of windows. Pgina introduced in this paper is one of the mature open-source solutions, and pgina is an open-source windows credential Provider authentication framework, through a variety of plug-ins in the form of C ා, we can customize the authentication process of windows, replace the traditional password authentication process, and connect with the unified authentication source to achieve the dream of unified SSO to some extent.

Introduction to pgina architecture

Pgina was first developed and open-source by David Wolff, etc. with the help of the credential provider system of windows, the icrendtialprovider interface was realized and the authentication process was customized. Mutonufoai maintains a fork version, which is an active branch at present. http://mutonufoai.github.io/pgina/

In short, after pgina is installed, we can insert a custom link into the authentication flow. Pgina natively provides a variety of plug-ins that can be used out of the box to connect with external authentication sources. For example, we can support OTP login through a custom radius authentication server or through the HTTP auth plug-in, or even more fine-grained control.

Pgina configuration

We take pgina access to radius authentication backend as an example to show the usage of pgina. It should be noted that pgina is not a central domain control plug-in. It needs to be installed and deployed on all specific target machines.

The pgina authentication process is divided into three stages: authentication – authorization – gateway. Among them, the authentication stage is used to prove whether the authentication credentials provided by the user are correct, while the authorization stage determines whether the user can log in when the credentials are correct (for example, only a certain group of users can log in), and the gateway stage is more similar to the callback after the authentication. For example, among many plug-ins, localmachine represents the native authentication on the machine. If other plug-in authenticated users do not exist on the machine, the localmachine plug-in will create corresponding users in the gateway phase by default. Of course, this behavior is configurable.

Support OTP authentication in Windows authentication through pgina plug-in

With these basic knowledge, we can connect to the customized radius server through plug-ins to enable OTP authentication support for windows. Restricted by the windows UI, users can append OTP before or after their original password. The overall process is shown in the figure below.

According to the above design, we can even, to some extent, abandon the existence of domain control system, and completely transfer the authentication source to a unified authentication system. Through the information carried in the plug-in, you can even limit specific permissions to specific machines to log in, and automatically refuse to log in when users are detected to have risks.

According to the actual test experience and problems encountered, the following suggestions are available for reference:

• The built-in plug-in can be used for quick test function, but there are not too many considerations in usability. There are some problems in the high-frequency use of radius plug-in itself. It is recommended to implement the plug-in by itself according to its architecture, and to realize the joint coordination between the self-defined authentication protocol and the remote authentication interface
• When the machine with plug-in authentication turned on is remote desktop (if remote desktop is allowed), the client side of remote desktop needs to turn off the default network level authentication, because the network level authentication does not support the customized credential provider. Turning off NLA does not cause security problems in authentication mode (such as hash being grabbed)
• The original version of pgina has debugging function, but the debugging function is difficult to use. It is recommended to debug in the form of log. Pgina.fork does not support debugging. The plug-in is mainly written in C ා language, which requires a certain understanding of C ා.

In addition, an obvious question is how to deal with the password of the original account? The localmachine plug-in of course supports the password of the original account to continue to take effect, but this will cause obvious shortcomings. A safe way is to issue customized scripts through terminal capabilities, and fully randomize the original account passwords on a regular basis, including local administrator users, domain users under the domain control system, etc. Of course, due to the consideration of disaster recovery, some accounts need to retain the original authentication capability in some ways for the use of troubleshooting when the user-defined authentication service is unavailable due to unexpected factors such as network, storage, etc. the specific details are not covered here.

summary

This paper introduces the pgina authentication system and its plug-in application. At the same time, a case is given by introducing OTP into windows authentication. Based on the plug-in capability, we can abandon some inherent weaknesses of domain control authentication system, introduce TOTP secondary authentication system, and unify the authentication back-end. The ability of API interface allows us to make a more unified and fine-grained planning for authentication rights, rather than sticking to the inherent system of Windows domain, reducing maintenance costs and improving security.

Note: This article has been authorized to launch at tiaotang sugar: https://tttang.com/archive/1282/