Practical Usage of ADSI: Managing User Accounts in Win2K and NT

Many systems administrators in large organizations spend most of their time with user and group management tasks. Although managing groups is generally a simple task to accomplish with Microsoft-provided tools, creating user accounts isn't. Typically, issuing an account to an end user involves many steps. In addition to creating an object in the namespace, you often need to create a home directory and corresponding share, then apply permissions in the file system. In addition, you often must grant group membership to a new user account so that the user can immediately gain access to shared resources.

Such multistep operations provide you with the perfect opportunity to use Active Directory Service Interfaces (ADSI) to create a complete solution that not only reduces the tedium of such administrative tasks but also reduces the risk of errors in these operations.

To create a user account, you typically need to perform these operations:

• Create a User object in the namespace
  
  
• Assign a password to the user
  
  
• Create a home directory for the user in the file system
  
  
• Set file-system permissions on the user's home directory
  
  
• Share the user's home directory
  
  
• Assign the user to additional security groups

Creating the User Object
To begin, you must create a User object in the namespace. For Windows NT domains and standalone machines, you always use the WinNT: ADSI service provider to create User objects in the SAM. For Windows 2000 domains, the general rule is to use the LDAP: ADSI service provider to create User objects in Active Directory (AD). This rule has two caveats:

• You can use the WinNT: provider instead of the LDAP: provider if you don't use any organizational units (OUs) in your directory and you define all the users in the default CN=Users container in the directory's root. Using the WinNT: provider in this situation enables backward compatibility with existing NT scripts. However, if you're not concerned with backward compatibility, the LDAP: provider is the best choice because it lets you take advantage of Lightweight Directory Access Protocol (LDAP)-specific properties, such as Manager, TelephoneNumber, or OfficeLocations.
  
  
• You can use the WinNT: provider instead of the LDAP: provider if the User object you want to create will exist in the SAM of an NT domain or local computer (i.e., a Win2K/NT standalone server or workstation) instead of in AD.

Let's look at how you can create a User object both in the SAM and AD.

Creating a User object in the SAM. The code in Listing 1 uses the WinNT: provider to create an object in NT's SAM (i.e., an NT domain or a Win2K/NT member server or workstation). Listing 1 begins by declaring and setting the variables. You need to customize the code at callout A in Listing

1. You must replace
   
   
2. Target_Container_Name with the name of the domain (for domain accounts) in which to create the account or the NetBIOS name of a local machine (for accounts on standalone machines) on which you want to create the account. An example of a NetBIOS name is Server_01. Optionally, you can add the resource domain for the server (e.g., Resource_Domain/Server_01) for faster binding.
   
   
3. Name_For_New_Object with the name of your new object (e.g., teck).
   
   
4. New_Password with the user's password (e.g., 1UsW2bT82!).

Next, you use the IADsContainer::GetObject method to bind to the target container. You establish the binding by concatenating the WinNT: provider (WinNT://) and the TargetContainer variable, which contains the domain or NetBIOS name.

After you bind to the container, you use the IADsContainer::Create method to create the User object in the cache. To write the object from the cache to the directory, you use the IADs::SetInfo method. Before you call this method, though, you can use the IADsUser interface to set any properties (e.g., FullName, Description) you want the object to have. Setting the optional properties before calling IADs::SetInfo conserves network bandwidth because the system writes to the directory only once. (For detailed information about IADsContainer, IADs, and IADsUser, see Alistair G. Lowe-Norris, "An ADSI Primer, Part 2: Manipulating Active Directory Objects," February 1999, and "An ADSI Primer, Part 6: Using ADSI to Create and Manipulate User Accounts," June 1999.)