How To Configure Access Controls With Active Directory

Access-control configuration poses several challenges for IT administrators. You must manage and delegate access for thousands of user accounts, integrate and aggregate various account repositories, set enterprise policies that may vary by department, and configure single sign-on, authentication, authorization and auditing. Identity-management apps can help, but they can be expensive and complex. There's an easier way.

Authentication is the process for identifying the user. It involves comparing user credentials entered at logon with the ones stored in a central repository. On Windows Servers, this is performed through Windows Authentication System and Active Directory. When the user is authenticated, the credentials, such as user name and password, are validated by checking policy rules. For example, the admin can set the user account or the password to expire, at which time Windows prompts the user to change them. Windows also can define minimum requirements for password length and complexity.

Once the user has logged on, authorization is the process that grants the user appropriate rights to various resources, including remote servers and files. Every resource (data object) is configured to grant access to users through access-control lists. The ACL contains a list of access control entries. Each ACE defines a permissible action that the user can perform on the object, such as "full control," "write only" and "delete." Since every user account has a unique security identifier (SID), the authorization server (domain controller) grants access to the resource by checking the SID against the ones stored in that particular resource's ACE. If the user SID matches the ACE SID, the user is authorized to access the resource with the permissions granted during authentication. Access controls can be set on every object and given to every user or group in the domain.

Active Directory provides secure storage for user credentials and the cryptographic keys that validate those credentials during the authentication process. AD complies with the Lightweight Directory Access Protocol and can interoperate and aggregate data with other LDAP directory services. AD supports a tree data structure of objects, called entries, that help manage company resources, such as computers and users, by mapping them to geographical and organizational attributes. The root of the tree structure is the company domain. Subdirectories consist of OUs (organizational units). OUs are directory containers for grouping accounts and machines.

Windows policies are configuration files that contain settings for accounts, passwords, user rights, auditing and other attributes. They can include information about the local machine (local policy) and/or the domain (domain policy). Group policies define security settings for computers and users and can be applied to directory containers according to site, domain or organizational unit. The computer section of the group policy is applied at bootup, while the user section is applied at login. Domain policies take precedence over local policies. Group policies override other settings when applied to subdirectories, such as OUs, but not domain account and password policies.For our Step by Step instructions, assume we want to create user accounts that belong to different departments in the organization, along with logon rules and access controls for such accounts. Users in different departments would get different access controls. In addition, we assume that AD is installed on our Windows 2000 server and that our server is the domain controller. If the AD is not installed, you can run the AD installation wizard by selecting Start/Run and entering Dcpromo.exe.

Marco Morana is an independent consultant specializing in the design and development of secure enterprise applications. Write to him at [email protected].

1 Configure Active Directory Create the directory structure and two top-level OUs: one for IT and one for the rest of the company. Access the AD "users and computers" MMC snap-in. Select the domain as root level. Right-click and select "New and Organizational Unit." Enter the object name. Click OK. Similarly, create a departments OU at the same root level of IT and create subdepartment OUs by selecting "Departments" as root level.

2 Create a user account Create a sales group in the sales department and users in both the sales group and IT department. Select the MMC Users and Computers snap-in, point to Sales and right-click on New and User. Fill in the New Object-User dialog box and click Next. When prompted, enter a password and an account policy rule. Then click Finish. Repeat the same procedure for creating a user in the IT OU. To create the sales group, select Sales and right-click on New and Group. Add the sales user account (jdoe, for example) by selecting user properties and the Member-Of tab. Add the sales group by clicking the Add button and choosing the sales group.

3 Create a Group Policy Object Select Sales OU and right-click on Properties. Then select the Group Policy tab and click New to edit the GPO name as Sales Policy.

4 Add Access Control Settings Click the Properties button. Select the Security tab and click the Advanced button to see additional permissions. The Access Control Settings will show the permissions for accessing the Sales OU granted to various groups and users.

5 Edit permissions for Sales Policy Click the Add button, scroll down to select user, computer or group. Select the sales group and click OK. The permission entry for Sales Policy will show up. Select the Full Control check box and then "Apply these permissions to objects and containers within this container only." Check the box and click OK. The permission entries for the sales GPO are shown. Click OK on the Access Control Setting for Sales Policy and OK on the Sales Policy Properties, and finally, close the Sales Properties Dialog. To further edit the Sales GPO, we can either reselect the Sales OU properties and modify the GPO policy or use the GPO MMC snap-in.

6 Edit the domain policy Enable the audit policy to check all the logon events to ensure access control is applied properly. The Domain Security Policy can be edited through the MMC snap-in by selecting Start/Programs/ Administrative Tools/Domain Security Policy. We recommend editing the security settings to assign password maximum and minimum age. We set the password minimum length to eight characters. By setting the account lockout policy, the admin can lock out a malicious user who tries to guess the right credentials by attempting several logons. We restrict the user to a maximum of four unsuccessful logins. To change that, select the Account Lockout Policy and double-click on Account Lockout Threshold, and set account lockout after four invalid login attempts. We also set the lockout duration and reset after 30 minutes.

7 Edit Audit policy settings We also want to edit the audit policy settings to log all the successful and unsuccessful login events along with object access and system events. Select Audit Policy in the Local Policies folder, double-click on Policy Audit Rules and check Define Policy Settings, success and failure. To have users log on interactively, select Edit User Rights from the domain policy/local policy/user right assignment, and enable access to authenticated users from local and network access. To have the new policy to take effect and the domain policy as well as group policy changes applied immediately for the server, you can reboot or issue the line commands: >secedit /refreshpolicy user_policy /enforce and >secedit /refreshpolicy machine_policy /enforce. To check if the domain policy has been enforced, open the local policy MMC snap-in and check that Local Security policy settings have been enforced to be the same as the domain policy settings.

8 Access Control Test As we log on as John Doe for the first time, the account policy in place will prompt us to change the password. If we try entering a blank password, we should be prompted with an error message. Once John Doe logs on as a member of the sales group, he is granted rights to change the security policy. We can change the Sales Policy Security Properties for authenticated users to give away the only rights previously set (read only), thereby denying access to other users. We then log on as IT User and try to access the Sales Policy to change security settings. Since we are not allowed to do that, we should be prompted with the error message as shown.

WEB MANUAL

See more information on group management in Windows 20000