A Complete Guide on Active Directory Certificate Services in Windows Server 2008 R2

Windows Server 2008 R2 includes a built-in Certificate Authority (CA) technology that is known as Active Directory Certificate Services (AD CS). The first iteration of AD CS emerged with Windows Server 2008, though previous versions of the technology were simply known as Certificate Services. AD CS can be used to create certificates and subsequently manage them; it is responsible for ensuring their validity. AD CS is often used in Windows Server 2008 R2 if there is no particular need to have a third-party verify an organization’s certificates. It is common practice to set up a standalone CA for network encryption that requires certificates only for internal parties. Third-party certificate authorities such as VeriSign are also extensively used but require an investment in individual certificates.
Note

Although the term Active Directory has been incorporated into the name of the Windows Certificate Services function, it should be understood that AD CS does not necessarily require integration with an existing Active Directory Domain Services (AD DS) forest environment. Although this is commonly the case, it is important to understand that AD CS has independence over AD DS forest design.
Windows Server 2008 R2 introduced a few additions to AD CS features, including the following:

Certificate Enrollment Web Service and Certificate Enrollment Policy Web Service— This is the most significant improvement, essentially allowing certificates to be enrolled directly over HTTP, enabling non-domain or Internet-connected clients to connect and request certificates from a CA server.

Improved support for high-volume CAs used for NAP— AD CS in Windows Server 2008 R2 improves the database performance when high-volume scenarios such as NAP are utilized.

Support for cross-forest certificate enrollment— AD CS in Windows Server 2008 R2 allows for CA consolidation across multiple forests.

Continue reading

Active Directory Domain Services in the Perimeter Network – Part 2

Let’s start this post with a question about RODCs (Read-Only Domain Controllers) because this post is all dedicated to placing an RODC in the DMZ (perimeter network):

Notes: From now on I will use the term DMZ instead of the perimeter network just to help my laziness.

Q: What are the benefits of RODCs in the DMZ?

Reducing the attack surface by placing an RODC instead of a writable domain controller.

-Giving directory service to applications that require access to Active Directory and are located in the perimeter network

Decrease the type of the traffic passing from the DMZ to the LAN and vice versa


You have to keep in mind that the clients and member server running in the perimeter network need to be Windows Vista and Windows Server 2008 and above, Otherwise a hotfix called RODC compatibility pack needs to be applied to them. You can download the hotfix from here. However you might not need to have the hotfix even but just to be on the safe side, do patch the clients and member servers using the hotfix.

Other recommendations about placing RODCs in the DMZ:

-Promote the server to an RODC on a Server Core edition of Windows Server 2008 R2

-If you have IPSec policies in your environment, make sure those IPSec policies are applied to the RODC so that it will be able to communicate with the rest of the members in the DMZ. There is something very important about IPSec policies on a DC:

Since all the member servers and possibly clients are going to communicate with the RODC using IPSec, bear in mind that the type of authentication used between the clients or servers and the RODC must not be Kerberos. There is one reason for that becasue the kerberos authentication is verified by the Domain Controller and if the client or server is not allowed to talk to the Domain Controller in the first place, how is it going to approve its authentication request? 

Therefore we need to use pre-shared keys or make use of Certificates (We need a CA Server) in order to authenticate the client. The use of certificates is preferable and is more secure than the pre-shared key.

-There is another question that comes up here and that’s if we have clients or serves that require dynamic updates on the DNS Zones in the DMZ, how are we going to handle that since we do not have a writable Domain Controller?

First of all apparently we hardly ever place a client in the perimeter network and if we do, the best security practice is to do a manual DNS update on the DNZ zone inside the LAN and then have it replicated to the RODC in the DMZ and you also need to disable dynamic updates on the client and servers in the DMZ.

Ports to be open on the firewalls:

Ports to be open on the firewall between the RODC in the perimeter network and the writable Domain Controller in the LAN:

Port Type of traffic
TCP 57344 DRSUAPI, LsaRpc, NetLgonR
TCP Static 53248 FrsRpc
TCP 135 EPM
TCP 389 LDAP
TCP 3268 GC, LDAP
TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc
TCP 53 DNS
TCP 88 Kerberos
UDP 123 NTP
UDP 389 C-LDAP
UDP 53 DNS
TCP and UDP 464 Kerberos Change/Set Password

Ports to be open on any host or network firewall between a member server in the perimeter network and the RODC in the perimeter network:

Port Type of traffic
TCP 135 EPM
TCP 389 LDAP
TCP 445 DFS, LsaRpc, NbtSS, NetLogonR, SamR, SMB, SrvSvc
TCP 88 Kerberos
TCP Dynamic DNS, DRSUAPI, NetLogonR, SamR
UDP 389 C-LDAP
UDP 53 DNS

That’s it for today with RODCs. I just tried to put things in a nutshell so that you can get the main points.

You want to learn more about this topic? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book:

To get more information about the book click on the book below:

1

Cheers

Active Directory Domain Services in the Perimeter Network – Part 1

In this new series of articles, I am writing about some stressful kind of Active Directory deployment which is the deployment within the perimeter network or the DMZ. Many people believe that deploying Active Directory in the perimeter network is not the right decision because of the security risks imposed on the organization’s directory service. In this article in the series, I am going to discuss different deployment models of AD in the perimeter network.

But before we start, there might be this question of why we need to deploy AD in the perimeter network in the first place and that’s simply because of the type of services being offered in that part of  the network to the outside users. There could be services like Sharepoint Server, SQL Server, Office Communication Server or even a VPN Server functioning in the perimeter network and all of them require access to the directory service of the network. So in any ways they require access to it and there should be a way of deploying that in the DMZ. this is WHY… So, below is an illustrated and descriptive list of different designs or models:

1- No Active Directory Domain Services

This simply means that we do not create any connectivity between the directory service in the network and any of the other services. You may prefer using the servers’ own SAM (Security Accounts Manager) database file which stores the local user and group accounts but that is tough, isn’t it? Having to create all those user accounts in all those servers and even making a change once in a while is another trouble. Besides, there are a lot of other disadvantages such a design could bring about like the lack of security, the lack of a central management and so more.

2- Isolated Forest Model

As it is shown in the picture, it is possible by creating two different forests for the intranet and the perimeter networks. In this way we have the directory service in the perimeter network but still the perimeter network is isolated from the rest of the network meaning that any update on the directory services inside the intranet (Like adding or modifying user accounts) will not affect the directory services in the perimeter network and vice versa. And the disadvantage with this design is the type of Domain Controller that you are going to put in the perimeter network in this design is going to be a writable one, so there is this risk that if the Domain Controller gets hacked, then the data on the Domain Controller could be in danger of modification and this change will be replicated to all the other Domain Controllers in the perimeter network. Another disadvantage is that there is no connectivity between the forests and if the domain users in the intranet require access to any of the resources in the perimeter network, it is not possible to give them such an access since there is no connectivity between the forests.

3- Extended Forest

In this model we have one single forest covering both the intranet network and the perimeter network. This could be a good or bad design depending on your choice.

The bad choice is when you put a writable Domain Controller in the perimeter network and since the data on the Domain Controllers gets replicated between the intranet and the perimeter network, any changes by a hacker on the DC in the perimeter network could be replicated to all the DCs inside the intranet.

The good choice is using a RODC (Read-Only Domain Controller) inside the perimeter network which is in replication with the DCs inside the intranet but are by nature Readable only or as we call them Read-Only Domain Controllers. This way if by any chance one of the DCs in the DMZ is at risk of getting penetrated, their data is not at risk of getting changed.

Later on we will talk more about the RODCs in this series.

 4- Forest Trust Model

This is one of the best designs where there is a separate forest for both the perimeter and the intranet networks just like the Isolated Forest Model but there is a trust between the two forests.

The trust could be unidirectional meaning that we can only let the intranet users access the resources inside the perimeter network. For example, if you have a SQL server in your perimeter network and you want both your intranet users and outside users to access that server, then you could follow this model to have two forests and make a unidirectional trust between them making the server in the DMZ accessible to the intranet users but still preventing the outside users in the perimeter network to access any of the resources inside the intranet.

A drawback to this model is the cost of administration of two different forests.

In this article, I just wanted to show you different designs and some of the advantages and disadvantages, in the next article I am going to extend this topic more.

You want to learn more about this topic? Check out my new book below and have access to great and practical tutorials and step-by-step guides all in one book:

To get more information about the book click on the book below:

1

Cheers

Notes: All the pictures are taken from Technet Documents.