The first constructor here is a basic default constructor that creates objects without any arguments. This means that the object will connect to the native WinNT provider without the specified security permissions.
second configuration enables us to specify a connection to the AD certificate to localized required, when using the given credentials needed to connect to any domain, this configuration is very convenient.
The second constructor adds the LoginPath parameter, which will allow us to override the LoginPath and be able to select a service provider other than the default provider.
The following code is what I call "active approach" code as follows:
public DSHelper.DSUser LoadUser (string username)
this method Used to receive the username and look for DirectoryEntry in the current provider. If not found, simply return NULL.
public System.Boolean AddUserToGroup(string groupname, DSHelper.DSUser dsUser)
This method receives the name of the existing group and an instance of the custom DSUser class, and attempts to add the user to the provided In the group. This is also the first method we can see impersonation (). The core of this method is the following line of code:
public System.Collections.ArrayList GetGroups()
We will use this method to get a list of all the groups in the domain.
public System.Boolean DeleteUser(DSHelper.DSUser dsUser)
This method gets the given username and removes it completely from the Active Directory.
public System.DirectoryServices.DirectoryEntry SaveUser(DSHelper.DSUser dsUser)
There is no actual ability to save and insert records in the database, it cannot be called a complete DAL. The above method can accomplish these two tasks. It first checks AD to see if a specified user exists. If it does, it will update the user with the data we provide. If the user does not exist, a user will be created.
public System.Boolean Connect()
Finally, we need a method to connect to the database, and Connect() is the method used to accomplish this task. It should be noted that at this time, it does not perform any fake operations or specify the certificate to use AD, we only provide the certificate when needed, which makes the DAL only read-only without providing a security certificate. Used under the state.
Here's a bunch of the above to see how we can use the DAL to create an ASP.NET user management page.
ASP.NET User Management Page
In this example project, we can enter a username and password for the system administrator user. It also provides a text box that we can enter into the domain. Any user's name will list all of its attributes. We can also edit, save, or completely delete the user.
Now let's review the entire project in detail, with the focus on the part that interacts with the DAL. Readers are considering using new methods to improve the interface and actually create a more usable and friendly design. In addition, readers can also consider how to create an interface using a console application.
Playing
The word "play" means that we perform operations as other people or users. In our ASP.NET application, this means that we can temporarily guest other users, rather than ASP.NET users that IIS uses to handle the default account for anonymous access. We want to be able to make our own code play other users with more access to AD resources in order to make appropriate changes to the resources. It is very simple to complete this process.
#region setup impersonation via interop
//To save the details, import from COM via InteropServices to complete the play
public const int LogoN32_LogoN_INTERACTIVE = 2;
public const int LogoN32_PROVIDER_DEFAULT = 0;
System.Security.Principal.WindowsImpersonationContext impersonationContext;
[DllImport("advapi32.dll", CharSet=CharSet.Auto)]public static extern int
LogonUser(String lpszUserName ,
String lpszDomain,String lpszPassword,int dwLogonType,int dwLogonProvider,
ref IntPtr phToken);
[DllImport("advapi32.dll", CharSet=System.Runtime.InteropServices.CharSet .Auto,
SetLastError=true)]public
extern static int DuplicateToken(IntPtr hToken, int impersonationLevel,
ref IntPtr hNewToken);
#endregion
Figure 1.5 Establishing Play< Br>
First, we need to import new methods from advapi32.dll, including some useful constants. A variable named impersonationContext will be used to hold the Windows user before the operation.
This way, we have established the play, here is an example of how to use it:
if(impersonateValidUser(this.LoginUsername, this.DomainName,
this.loginPassword)) {
//In this case, insert the code that runs under the security environment of the specified user
//Do not forget to cancel the play
undoImpersonation();
} else {
//The play operation failed, Plug-in guarantees system security after failure
}
Figure 1.6 Plays with
We just need to call the impersonateValidUser method with a valid username and password to play the user. From now on, we will perform all operations with the given username only after calling undoImpersonation().
In order to make the play operation under ASP.NET work normally, we should change the machine.config (c:\\winnt\\microsoft.net\\framework\\v%VERSION%\\config\\machine.config) The processModel node, where the username attribute must be set to System.
This article discusses the basics necessary to use the System.DirectoryServices namespace to complete a fully functional DAL for any provider AD. In practical applications, the example can be changed to make this more in line with our requirements. It is important to remember that for any DAL that can actually be used, it should not be limited to only one service provider, including a normal database provider. We should be able to exchange DAL.
After reading this article, readers may feel that there is a feeling of inadequacy. Readers may wish to add group management features, including group creation, editing, and deletion, and display the groups that each user belongs to and the users in each group. However, these need to be completed through COM Interop, please read the relevant information.