In this Chapter
Smartcards and other security hardware have been around for several years. Most of the implementations of such devices have been at very large organizations, such as government agencies in the Unites States and in Europe. This mainly has been due to slow adoption and perceived difficulties in implementation.
Windows Server 2003 has made the deployment of such security devices much more straightforward. The incorporation of Group Policy templates, autoenrollment, and Windows XP’s features as the certificate client has given the administrator much better tools with which to work.
Creating a Public Key Infrastructure (PKI) environment takes quite a bit of time and planning to build and effort to maintain. Administrators often have to plan well beyond the current levels of hardware and software available to them at the time of implementation. If the company’s PKI infrastructure was built on Windows 2000 the administrators may want to improve their environment with new functionality built in to Windows Server 2003.
With the advancements in Windows Server 2003’s Certificate Services and Group Policies much of the administrator’s time, planning, effort, and wishes will finally pay off. Creating and issuing certificates to computers and users has become much easier to deploy and ultimately to maintain and manage.
Administrators have at their disposal a very cost-effective platform to deploy a PKI infrastructure on Windows Server 2003. The new features that are available with this product are as follows:
Cross Certification. The Certificate Services in Windows Server 2003 has demonstrated full compliance with the U.S. Federal Bridge Certificate Authority (FCBA) requirements. The FCBA is a nonhierarchical PKI architecture that permits heterogeneous PKIs from different U.S. government agencies to be cross-certified and interoperate between organizations. This feature creates a certificate trust path between participating domains.
Flexible Certificate Templates. Windows Server 2003 supports both the Windows 2000 (version 1) and the new version 2 templates. Management of the templates is controlled through the new Certificate Templates MMC snap-in. This new tool enables administrators to control template properties (such as key size and renewal period), permit autoenrollment and autorenewal for both users and machines, set access control on certificate templates to determine which users or machines can enroll for certificates, and allow for specific Cryptographic Service Provider (CSP) use and key size.
Certificate Autoenrollment. Administrators can specify the types of certificates a user or machine can automatically receive on logon. If the access controls permit, a Windows XP or Windows Server 2003 client can access the templates in Active Directory and enroll for their respective certificates.
Autorenewal. Administrators can use the new templates to permit the autorenewal of a user or machine certificate. This removes the administrative overhead of managing certificate expiration.
Role-based Administration. Windows Server 2003 makes it possible to enforce the separation of the many administrative roles for the CA and operating system. With different roles no single user can compromise the entire CA.
Key Counting. The CA now supports key counting, where the CSP maintains a count of each use of the signing key. This feature provides additional audit information that can be used to track private key distribution.
Key Archival. The CA now has the ability to archive the keys that are associated with the certificates it issues. These keys can now be recovered using the new key recovery agent certificate.
Delta Certificate Revocation Lists (CRL). The CA can now provide delta CRLs that are in compliance with IETF RFC 2459. This reduces the CRL network traffic because the complete replication of the full CRL database is not required for a small number of certificate revocations.
Event Auditing. Most events that occur on the CA server can be audited. This provides a useful logging and monitoring function. Examples of this are tracking role changes, key recovery, certificate issuance, and revocation of certificates.
Administrators have many choices in their enterprise security architecture. One of the choices related to PKI and smartcard secured access is the deployment of the CA roles within their organization:
The Server Does Not Have to Be a Domain Controller
Administrators can install an Enterprise CA on any domain member server. The server does not have to be a domain controller. This practice is especially important for security concerns and separating CA roles.
The most important CA role, as it relates to smartcard deployment, is the Enterprise Root CA. The Microsoft Windows Server 2003 Enterprise CA has the following characteristics:
The Enterprise CA must be a member of a Windows Server 2003 Active Directory domain.
The Enterprise Root CA certificate is automatically added to the Trusted Root Certification Authorities node for all users and computers in the domain.
User certificates can be issued that allow users to log on to the Active Directory domain using computer-stored certificates and/or certificates stored on smartcards.
User certificates and the Certificate Revocation List (CRL) are stored in the domain’s Active Directory.
Unlike Standalone CAs, an Enterprise CA issues certificates via certificate templates that can be added and customized by the CA administrator.
Unlike the Standalone CA, the Enterprise CA confirms the credentials of the user requesting a certificate.
The Computer or User name (also known as the Subject) can be entered manually or automatically on the certificate.
For Administrators to Enable Support of Certificate Autoenrollment...
For administrators to enable support of certificate autoenrollment, the Enterprise CA must be installed on either a Windows Server 2003 Enterprise or Datacenter Edition server.
Using the Web Enrollment Site to Obtain Certificates
Users and computers that are not domain members, or don’t support autoenrollment, can use the Web enrollment site to obtain certificates.
The Enterprise CA is an ideal solution for a network with a Windows Server 2003 domain. All domain members can be assigned certificates via Group Policy–based certificate autoenrollment. You can limit the scope of autoenrollment by assigning permissions to the certificate template.
By using the security access philosophy of “Something you know, something you have, and something you are,” information technology administrators can significantly increase their network security. The more you can do to keep people from impersonating valid log-in attempts, the more secure the data and network resources will become. To detail the best practices that lead to secured information system access, the three items are as follows:
Something you know. This can either be a strong password, or in the case of a smartcard this would be the user’s personal identification number (PIN).
Something you have. This is any of several devices that contain a copy of the user’s PKI certificate. Examples are smartcards and USB keys.
Something you are (optional). This refers to some physically unique attribute of the user. Examples are DNA, fingerprints, facial features, or the iris of the user’s eye.
End users in a less than secure environment can easily use someone else’s username and password. This is especially open to attack when the impersonator is coming from a remote location. No one is watching the attacker sit at a remote terminal and access all the company’s data.
By using a physical device such as a smartcard, secure ID, or other device, administrators can be more assured that users are actually who they say they are when they log-in.
The machines that are authenticated in Active Directory are usually known entities. This piece of information gives you a good idea of where the user is logging in from.
Sending certified, or signed, e-mail in an application such as Outlook can be performed using smartcards. Using certificates stored on the smartcard to sign the end-user’s e-mail enables the recipient to know that the sender is who he actually says he is. Certificates can also be used to make sure that only the intended recipient can open and read the e-mail sent.
Encrypted File System (EFS) can be employed to secure sensitive company data. This is especially critical for administrators who are tasked with protecting data on laptops and other portable devices.
Windows Server 2003 now supports EFS on offline folders and multiple user access. It is also harder for unauthorized recovery of EFS folders by third parties. EFS renders the data unreadable to anyone who is not granted access to that content.
Smartcards can be incorporated into a company’s identity badge that has a radio frequency identification (RFID) capability. Card readers can be installed on the exterior, or on critical access internal doors.
Maintaining an accurate record of smartcard holders and what level of access they have can be extremely useful. All entry accesses can be centrally logged and can be audited by the administrator or security personnel.
Standalone and Enterprise Root servers contain the single copy of the company’s private key. This component is essential in authenticating any and all access to the PKI-secured data and entry points.
Physical security and data security are both very important tasks in an administrator’s role.
Microsoft provides very well-defined baseline security guidelines for locking down the operating system, IIS, and administrative access.
Change the local administrator and guest account names. Don’t use the same administrator and guest account name on every server.
Placing more than a single role on a server makes an attacker’s job easier. It then becomes possible to compromise several roles in the company’s PKI infrastructure. Certificate Services storage and enrollment can be separated. The following list includes some of the tiers that can be physically placed on separate servers:
Administrators need to work with senior executives to define the roles that will be assigned to personnel within the company when it comes to managing the PKI and smartcard system.
The persons entrusted with issuing smartcards within an organization are known as enrollment agents. Enrollment agents are typically members of the help desk, IT security, or company security staff. In locations where one of these personnel isn’t readily available another trusted individual such as that location’s supervisor or manager can be the enrollment agent.
Delegating the authority to issue smartcards has administrative as well as security benefits. Some of those benefits are listed here:
Administrators can delegate this time-consuming process.
Enrollment agents process all certificate and smartcard requests.
Smartcard users can be stepped through the enrollment process.
There are also some disadvantages to delegating smartcard enrollment. Here are several points to consider:
Any security measure that makes it harder for end-users to do their job is never accepted whole-heartedly. Administrators have to perform extensive planning and usability studies within their organizations.
Contact-less Smartcard Support
Windows Server 2003 and Windows XP do not support the type of devices known as contact-less smartcards.
There are a variety of smartcards and USB tokens from which to choose. Smartcards that are used in a Windows Server 2003 environment run on the Microsoft Smartcard operating system. Smartcards and their readers must adhere to the ISO 7816 standard. To ensure compatibility you should always test the smartcard with the reader and confirm that USB ports will be available for token type devices.
Administrators have to plan for the usage requirements for the smartcards or USB tokens. The following list includes some considerations for the physical card or token:
Smartcards and tokens use their memory to store the certificate of the user, the smartcard operating system, and additional applications. To use the smartcard in a Windows logon environment, you must be able to program the card to store the user’s key pair, retrieve and store an associated public certificate, and perform public and private key operations on behalf of the user (enrollment agent).
Smartcards come in two common memory configurations—8KB and 32KB. To use the Microsoft Smartcard operating system, you need to specify the 32KB device.
Maximum Length of User’s Logon Certificate
The maximum length of the user’s logon certificate is 1,024 bits due to fact that it is the largest certificate that will fit in the 2.5KB space provided on the smartcard.
The components that make up the memory storage requirements on a typical 32KB smartcard device are listed in Table 3.1
Table 3.1. Typical Smartcard Memory Use (32KB Device)
Content | Memory Used |
|---|---|
Windows for Smartcards operating system | 15KB |
Smartcard Vendor Applications | 8KB |
Smartcard logon certificate | 2.5KB |
Company Custom Applications (if any) | 1.5KB |
Free Space | 5KB |
The memory configuration of the smartcard is ultimately up to the company and the administrator. Smartcards can be divided into public and private memory spaces. You can define separate protected memory for the operating system, certificates, e-wallets, and other applications. This section of the card’s memory can be allocated as Read Only.
The memory capacity on smartcards is increasing as vendor technology improves. This allows for more applications and certificates to be stored on the card or token. Multiple uses can be specified for the cards and the memory requirements that affect these applications should be taken into consideration when deciding to purchase such devices.
Administrators have three roles of smartcards at their disposal. When planning the company’s smartcard deployment you need to determine the number and type of each card.
Enrollment cards are issued to personnel who will be enrolling smartcards on behalf of other users. These cards have a special enrollment agent certificate that enables the card’s user to act on behalf of the administrator.
User cards can be permanently issued and point to a permanent certificate server
User cards can also be temporary use cards that point to temporary certificates.
In better defining the user cards, the two types are as follows:
Permanent cards are issued to the employees to be carried with them at all times. These cards contain the cardholder’s credentials, certificates, data, and custom applications. Customization of the cards might include company logos and a photograph of the cardholder.
Temporary cards are issued for limited-use and are issued to users such as guests, temporary employees, and employees who have forgotten their permanent cards
Administrators must take into account a few factors when deciding on the type and durability of the smartcards or tokens. These considerations should be based on the normal wear and tear expected on the device and the length of end-user’s usage.
When purchasing the smartcard device you should ask the vendor(s) for expected lifetime documentation for the device
The physical device that the computer uses to interface with the smartcard is known as the “smartcard reader.” The readers come in a few form factors, including USB, RS-232 serial port, and Personal Computer Memory Card International Association (PCMCIA) Type II slot.
The USB style token device is the simplest of the smartcard/reader combinations because it doesn’t require a separate smartcard reader. One item to consider when choosing this type of device is the physical availability and access to open USB ports on the end-user’s computer.
You need to evaluate the bundled software that comes with the smartcard or token device. The management software can enable you and the company’s developers to customize the memory allocation and custom applications.
Some smartcard and token device manufacturers supply additional security management software as well. This is important when the deployment of smartcards is transitioning from pilot to production as well as maintaining the user’s smartcard credentials on the devices.
Custom application development requires a robust application programming interface (API) from the smartcard vendor. This is especially important when combining multiple uses of the smartcard such as building access and secure logon and application access.
By using group policies you can enforce user’s behavior. The policies that affect smartcards are shown in Figure 3.1 and Figure 3.2.
Many company expenditures are underused, if used at all, because of increasing end-users perceived complexity. The smartcard is one device that can make the users’ experience actually become easier.
Users will find that they don’t have to memorize those hard-to-remember strong passwords. Administrators won’t find yellow Post-it notes with the user’s strong password stuck to the lower-corner of the user’s monitor or under her keyboard.
More laws are passed every year that place companies and consultants at risk of not protecting users and client’s data.
To Take Advantage of Windows Server 2003 Auditing...
To take advantage of Windows Server 2003 auditing you need to enable Audit object access by using the Group Policy Object Editor and drilling down to Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy and double-clicking on Audit Object access.
By verifying who a user is and when and where he signed on to the system, it makes it easier to prove that person’s identity and possibly his intentions.
Security and financial auditors need to be able to read reliable reports of not only hacking attempts but also normal day-to-day network usage and system access.
Administrators of Windows Server 2003–based CA servers can provide reporting on the following functions.
The CA audit log generates two types of events:
Access check
System events
CA-related system events are generated in seven key categories:
Back up and restore the CA database
Change CA configuration
Change CA security settings
Issue and manage certificate requests
Revoke certificates and publish CRLs
Store and retrieve archived keys
Start and stop Certificate Services
Administrators can enable and configure CA event auditing by performing the following steps:
Log on to the server with an account with one of the following permissions: Domain Administrator, Certificate Authority Administrator, or Certificate Authority Auditor.
Click on Start, Programs, Administrative Tools, Certification Authority.
In the console tree, right-click on the name of the CA on which you want to enable event monitoring and select Properties.
On the Auditing tab, click on the events to audit as shown in Figure 3.3.
Using certificates and smartcards to secure access to the network relies on several factors including practicing good firewall procedures, securing certificate authority servers, and tracking user access.
This section describes the benefits of a well-run smartcard enrollment and authentication strategy. These techniques are only as secure as the underlying practices that exist in the enterprise.
As the old adage goes, keep honest people honest. Physical security is probably one of the most overlooked practices in a Windows-based network. Because of the friendly interface many administrators make the mistake of treating their Windows servers like any another desktop. Having the server’s console invite you to sit down and see what you can change or peer into is just too tempting. This is especially likely when administrators walk away from the console while still logged in.
Lock your servers away. If a secure room isn’t available, at least use a lockable server cabinet. If this isn’t an option you can always remove the monitor, keyboard, and mouse. The server will still run and you can use Terminal Services to manage the server.
Keep backups in vaults. If the company doesn’t have access to a storage vault, any off-site facility with reasonable physical security will do. Even if this means that you rotate backup sets at home.
If security measures are too hard to use or remember users won’t use them. Using devices such as smartcards actually make the company’s security policies easier to implement due to users not having to suffer through strong passwords.
If security measures are too hard to use or implement administrators won’t want to roll them out. Microsoft and other vendors are making the securing of networks and user access more straightforward and easier to manage. Administrators are then able to create a more secure computing environment for their company and end-users.
Some of the best practices that are relatively simple but effective involve the use of naming conventions, security roles, and client access control. When the simple processes are followed, it’s easier to cover your tracks that make it more difficult for a hacker to gain access to your systems.
Don’t advertise your systems. By using naming conventions that are somewhat cryptic, administrators can keep someone who is looking at the network from knowing which machine performs which role.
Don’t broadcast your network vulnerabilities to outsiders by leaving nonessential system services running. Services such as file transfer protocol (FTP) are constantly polled by port scans. After someone knows which services are running they can then employ tools and bots to try and break into the system.
Another good practice is changing the port number that required services are running on. This method of security is best deployed when you can control the client’s applications that are accessing the company’s network based services.
Allowing access to the network and system resources by entering a single username and password is the holy grail of the network administrator. Using certificate services and smartcard devices can make this goal a reality.
The new Active Directory credential manager provides a secure store for user’s X.509 certificates when used in conjunction with Windows XP credential management, which has three components; credential prompting user interface, stored user names and passwords, and a keyring to store PKI certificates. Together these infrastructure components form a single sign-on solution.
If feasible, a company can standardize on Windows Server 2003 Active Directory. Consolidate LDAP directories. Active Directory can become the single repository for the company’s users, machines, log-in credentials, and contact information.
Security requirements on applications can be quite numerous. Inventory the current applications and their business purposes and security requirements. After administrators take the inventory of all the applications in the company some can be absorbed into other applications. Many applications are reliant on their underlying file system structure for their security. By reducing the number of applications and securing fewer network shares you can more easily allow and track access to those applications.
Using the smartcard to store the user’s credentials to access any number of Web-based servers and services can greatly reduce the risk of impersonation. Ensuring the user is using two-factor authentication also allows for better tracking and auditing of network resource access.
By locking down access to IIS 6.0 Microsoft has created a more secure by default design. The baseline security of the server enables you to decide which virtual doors to open to outside users of the Web-based applications.
Directory access is a primary concern with both Web and locally accessed file-based applications. Administrators must create the proper groups and grant those groups the appropriate level of access to the resources. Granting execute access to the appropriate directories where applications are contained is fundamental in securing the company’s Web-based applications.
If the keys to the kingdom are hanging on a hook next to the front gate things are not very secure. Hackers know very well where applications are open. By moving things around a little bit it makes the opposition work a bit harder in compromising your network.
Moving ports can make port scanning less effective in finding which services are running on the network servers. All applications are listening on well-known TCP ports. Examples of common ports are as follows:
Bad things happen to good administrators. No matter what one does, hard drives go bad, power supplies burn out, and files get deleted. By keeping these inevitabilities in mind, you can protect yourself from accidental deletion and equipment failures.
No single point of failure is a common planning scheme among network administrators. If you have at least two of everything you can afford to lose one without user downtime. Administrators deploying a PKI environment with multiple tiers can deploy several layers of fault tolerance such as the following:
Administrators have the unenviable role of bringing lost data back from the netherworld or raising servers from the dead. By planning for failure you can create a disaster recovery plan of action and spare server parts and roles.
Tracking changes is important because restoring an old copy of a server can take the company back several weeks if not break the applications altogether.
Perform the following steps when backing up a Certificate Authority:
Log on to the system with at least Backup Operator or Certification Authority Administrator privileges.
Click Start, Programs, Administrative Tools and double-click Certification Authority.
In the console tree, right-click on the name of CA server that you want to back up.
Choose All Tasks/Back up CA as shown in Figure 3.4.
Administrators can extend the security of their smartcard desktop enrollment and usage. Smartcards can replace the user’s need to memorize passwords on Windows-based mobile devices as well. The same certificates stored on the smartcard to log on to the PC can be used to access the company’s network and applications via Pocket PCs and Windows-based Smart Phones.
Pocket PCs can be equipped with third-party smartcard readers to perform such tasks as Internet authentication or intranet security.
Pocket PCs use a certificate solution with smartcards based on the Windows CE Cryptographic Service Provider (CSP) for the specific brand/type of smartcard.
On a Pocket PC the CSP performs the following functions:
Provides a CSP interface compatible with the Microsoft RSA provider.
Uses the smartcard to save private keys securely.
Uses the smartcard to perform private key operations such as key exchange and digital signing.
Restricts access to private key operations with a user-supplied PIN.
The Pocket PC can be used as an enrollment station by implementing the KP_CERTIFICATE property.
When used with smartcard enrollment the Pocket PC should extract the certificates stored on the smartcard. The Pocket PC saves them to the local system store for use by applications. The Certificate Management control panel applet can be used to perform these enrollment steps.
Mobile User Authentication of Global System for Mobile Communications (GSM) has, to date, been performed by a smartcard known as a Subscriber Identity Module (SIM) card. As of January 2000, there were more than 250 million smartcards being used in the mobile telephone industry.
Microsoft Smart Phones are based on the Windows CE operating system and will be able to take advantage of similar smartcard certificate management as the Pocket PC. Applications that use smartcards for certificate storage and computation will also work similarly to those on the Pocket PC.
Smartcards have become an important component in the security strategy of organizations. Rather than relying on logon name and password, an organization that implements smartcards is leveraging two-factor authentication. Two-factor authentication that uses a combination of a logon/password sequence as well as the insertion of a physical smartcard device drastically improves network security in a Windows networking environment.
An important factor in setting up a secured smartcard environment is to start with a secured Certificate Authority setup. By minimizing access to the CA server, an organization can minimize the chance of unauthorized certificate creation and other key component factors in maintaining a secure authentication environment.
Smartcard administration such as issuing smartcards, managing smartcards, and applying the appropriate level of security for users also becomes a task for network administrators to manage. Fortunately with Group Policies built in to Windows Server 2003, the task of an administrator can be automated by specifying key security requirements for smartcard access.