Windows Server 2003 (Part 2)

The next feature that this domain level offers is constrained delegation. To understand this concept, first you will need to know about delegation. Consider this example where delegation would come into play. An administrator wants to install an application on a user’s computer. He sends his username and password to the client’s computer which allows him access. The administrator then sends a command to the client’s computer telling the client to connect a file server to get the install files.

In order for the client’s computer to do this, it needs a username and password to access the file server. In order to protect the install files, you would want to make them available only to an administrator. This is where the problem comes in. In order for the client’s computer to access the shared file, it needs to pass on the administrator’s credentials to the file server. When this occurs, it is called delegation.

The problem with delegation is that a virus on the client’s computer could get the administrator’s username and password and use it to access any computer on the network. This is why delegation in this form is disabled by default.

With the Windows-Server-2003 domain functional level, you can enable delegation but may restrict it to particular services to be accessed. This provides a safer way to use delegation than previously. To illustrate this, I will open Active Directory users and computers from the start menu.

I will navigate to the computer’s organizational units and select the properties for one of the computer accounts. Once I select the delegation tab, I can see the current delegation is set to off, which is the default. The next option is to trust delegation but only when using Kerberos.

Kerberos is a great security protocol but a problem could occur if the administrator’s computer was to become compromised and thus computer was trusted for delegation. This computer could then be used as a stepping stone to access any computer on the network.

The next option is added by the Windows-Server-2003 domain functional level. This allows you to trust the computer for delegation but to specify which services are allowed. If hackers were to take advantage of delegation, they would be limited to the services listed and thus the possible damage they could do is reduced.

By default Kerberos will be used, but if you need to, you can change the option to accept any valid protocol. If I now select “add”, I can select the users or computers that I want this computer account to be trusted to use.

If I only wanted the computer account to be trusted to read install media stored on DC1 (domain Controller), I would select CIFS, a protocol used by Windows File Sharing. What this means is that an administrator could send their username and password to this computer telling it to install an application. The application install files are located on DC1. In order to access these files, DC1 will need a username and password. Since the work station is trusted for delegation for file sharing only and only to DC1, it can pass the administrator’s username and password to DC1 to access the files. For ultimate security you could make the file share on DC1 read only. 

Other remaining features will be discussed in Windows Server 2003 (Part 2) Windows Server 2003 (Part 2).

Windows Server 2003 (Part 1)

In the following paragraphs we will discuss some features of Microsoft’s Windows Server 2003 Windows Server 2003.

With the Windows-Server-2003 domain functional level, you do get some new features. The first feature is the ability to rename the domain controller. Previously you would have had to remove Active Directory from the domain controller, rename the domain controller, and then get the server return to the domain controller. With the Windows-Server-2003 domain functional level, you don’t have to demote the domain controller to a server in order to rename it.

The second feature adds new attributes to Active Directory.  One new attribute is last login time stamp. This is a useful feature that allows you to determine when a particular user logged on to server’s domain. Using this feature, you can run a query on your domain, helping you to find any users that have not logged on for a long time and thus clean out some inactive users.

Every object in Active Directory has attributes and Open ADSI can be edited from the admin tools. This tool allows you to view and edit attributes in Active Directory.

If you open the users’ folder and then open the properties of the administrator account, this will show all the attributes that are assigned to the administrator account. If you go down to Last Logon Time Stamp, you will see the date and time the administrator last logged on. This is only one of the attributes each user has. You can see how Active Directory can be extended to embrace novel attributes.

Windows-Server-2003 domain functional level also includes support for an additional attribute called user password. This is added to an object called INetOrgPerson. The INetOrgPerson object is a storage object for a user from a non Active Directory system. If you use another directory service, you may want to migrate to Active Directory or use both systems together. The problem with using another active directory service is the user password.

This domain functional level adds support to store a password from a 3rd party directory service inside the INetOrgPerson object. This essentially means that you can import a user and their data from another directory service into Active Directory via the INetOrgPerson object. Since this now contains a user password attribute, Active Directory can use the password in the INetOrgPerson object to log the user on to the domain. Previously the user would have needed to have their password reset or they would have needed to use two passwords, one for Active Directory and one for the other system. With the new user password attribute, linking other directory systems with Active Directory is a lot easier.

The next feature added is selected authentication. This feature allows you to specify the users and groups from a trusted forest who are allowed to access resources. This allows you to put more controls on access when you work with multiple forests.

Another feature that Windows-Server-2003 domain functional level adds is support to store authorization manager polices. Authorization manager is a flexible framework for integrating access controls into applications. With this domain functional level, you can now store authorization manager polices in the Active Directory database.

Other remaining features will be discussed in Windows Server 2003 (Part 2) Windows Server 2003 (Part 2).