I recently worked an odd case where customer was seeing the below error on some of his certificates in the Trusted Root Certificate Authority store. This was only the case for some certificates and happened on several different Operating Systems. The customer was thinking that something had corrupted the certificates but even downloading them from Verisign and importing them made no difference.

We asked customer to save that certificate to a file and then run a certutil command against it and send us the output. Command was certutil –verify SavedCert.cer > verify.txt

Below is the output from verify.txt

Issuer:
    OU=Class 3 Public Primary Certification Authority
    O=VeriSign, Inc.
    C=US
  Name Hash(sha1): 48b76449f3d5fefa1133aa805e420f0fca643651
  Name Hash(md5): 27b3517667331ce2c1e74002b5ff2298
Subject:
    OU=Class 3 Public Primary Certification Authority
    O=VeriSign, Inc.
    C=US
  Name Hash(sha1): 48b76449f3d5fefa1133aa805e420f0fca643651
  Name Hash(md5): 27b3517667331ce2c1e74002b5ff2298
Cert Serial Number: 70bae41d10d92934b638ca7b03ccbabf

dwFlags = CA_VERIFY_FLAGS_CONSOLE_TRACE (0x20000000)
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
HCCE_LOCAL_MACHINE
CERT_CHAIN_POLICY_BASE
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwErrorStatus = CERT_TRUST_IS_NOT_SIGNATURE_VALID (0x8)
ChainContext.dwErrorStatus = CERT_TRUST_HAS_WEAK_SIGNATURE (0x100000)
SimpleChain.dwErrorStatus = CERT_TRUST_IS_NOT_SIGNATURE_VALID (0x8)
SimpleChain.dwErrorStatus = CERT_TRUST_HAS_WEAK_SIGNATURE (0x100000)

CertContext[0][0]: dwInfoStatus=c dwErrorStatus=100008
  Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
  NotBefore: 1/28/1996 7:00 PM
  NotAfter: 8/1/2028 6:59 PM
  Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
  Serial: 70bae41d10d92934b638ca7b03ccbabf
  74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2
  Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
  Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
  Element.dwErrorStatus = CERT_TRUST_IS_NOT_SIGNATURE_VALID (0x8)
  Element.dwErrorStatus = CERT_TRUST_HAS_WEAK_SIGNATURE (0x100000)

Exclude leaf cert:
  da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Full chain:
  74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2
  Issuer: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
  NotBefore: 1/28/1996 7:00 PM
  NotAfter: 8/1/2028 6:59 PM
  Subject: OU=Class 3 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
  Serial: 70bae41d10d92934b638ca7b03ccbabf
  74 2c 31 92 e6 07 e4 24 eb 45 49 54 2b e1 bb c5 3e 61 74 e2
A signature algorithm or public key length does not meet the system's minimum required strength. 0x80094016 (-2146877418)
------------------------------------
CertUtil: -verify command FAILED: 0x80094016 (-2146877418)
CertUtil: A signature algorithm or public key length does not meet the system's minimum required strength.

The last line had me thinking, okay what was done to this system that is not allowing it to use a self-signed certificate that is in the Trusted Root store? As you can see the Public Key length is 1024 (below).

I did some research and found this KB.

https://support.microsoft.com/en-us/kb/2661254

Using the above KB I realized that someone must have set a registry key that does not exist by default.

HKLM\Software\Microsoft\Cryptography\OID\EncodingType0\CertDllCreateCertificateChainEngine\Config and added DWORD minRSAPubKeyBitLength

They set it to at least 2048 which causes the above certificate to display the error about integrity.

You can find out if that registry key exists by running certutil -getreg chain\minRSAPubKeyBitLength and if it exists at all it will give a value. If it does not it will error (below).

You can set it using certutil -setreg chain\minRSAPubKeyBitLength <value> where value can be 512, 1024, 2048, 4096, etc. So certutil -setreg chain\minRSAPubKeyBitLength 2048 would set it to 2048 bits

To delete the key altogether use certutil -delreg chain\minRSAPubKeyBitLength

Once the key was deleted the error was no longer seen on any of Trusted Root Certificates.

Cheers!

I recently had another very interesting case that I thought I would share. This is a follow up post to a previous blog I did on this issue which is located here.

The symptom, cause of the behavior on the iPhone, and diagnosing the issue were identical but it was the root cause and resolution that were different.

Symptom:

Your Exchange data may unexpectedly reload on some or all of the iOS devices in your organization. This includes Exchange email, contacts, and calendar information.

Environment: Exchange 2007, Exchange 2010, or Exchange 2013 published externally using Internet Security and Acceleration (ISA 2004 or ISA 2006) Server, Forefront Threat Management Gateway 2010 (TMG 2010) or Unified Access Gateway 2010 (UAG 2010) as well as F5 Big IP.

Cause:

This issue is seen when the iOS devices receive an HTTP 500 error in response to consecutive requests. The ping that the client initiates is critical to the Direct Push technology that Exchange ActiveSync relies on for determining when there is new information to be pushed to the client.

For more information on Direct Push and how it works see the below links:

https://technet.microsoft.com/en-us/library/cc182244.aspx

https://technet.microsoft.com/en-us/library/cc182236.aspx

Diagnosing this issue:

Apple has addressed this issue on their support forum here and has some recommendations for diagnosing this at the client. It is my understanding that Apple support has to pull the ActiveSync logs off the iOS devices.

From the ISA/TMG standpoint, diagnosing this involves a couple of things. Start Live Logging on ISA/TMG and filter for traffic that is using the ActiveSync rule for your organization. If there are multiple requests that are showing as Failed and an Error 64 is indicated as the cause then we need to investigate further.

A Microsoft Support Engineer can gather application level tracing using our Best Practices Analyzer  and more specifically the Data Packager.

In the ISA/TMG tracing which will need to be converted by Microsoft we will typically see ActiveSync conversations failing with error code 64(ERROR_NETNAME_DELETED) and will be followed by a response to client of HTTP/1.1 500.UAG Tracing would not show the (ERROR_NETNAME_DELETED) but you should still see a HTTP/1.1 500 being returned to the client. 

Resolution and Root Cause:

To determine the root cause and the ultimate resolution to this issue I took the same approach that I have in all of these cases. First I wanted to eliminate my product (TMG in this case) as the culprit. Out of the box ISA and TMG will publishing your Exchange ActiveSync Services without an issue. I have never seen a case where either one was contributing to this issue and I have worked quite a few of these over the last few years.

In order to eliminate TMG as the culprit I had the customer gather data using our TMG Data Packager (Web Proxy and Web Publishing scenario) while reproducing the issue. Thankfully this issue consistently occurred in this environment after exactly 5 minutes (300 seconds). Another thing that worked in our favor was that customer was able to recreate this in their test environment which closely mimicked their production environment.

The data flow was essentially Client ======> F5 ======> TMG ======> F5 ======> Exchange CAS

Based on the tracing I gathered from TMG I was able to determine that the RST was happening somewhere between TMG and the CAS Server. This lead me to strongly suspect that F5 was to blame. A network trace from the CAS Server showed the RST was happening between TMG and CAS as well.

In previous troubleshooting for this issue the customer had discovered that F5 defaults to 300 second timeouts for many of its settings. This falls in line with what we were seeing in terms of a time frame. These timeouts were adjusted and the customer even bypassed F5 as a load balancer and yet the issue persisted.

Digging a little further with the help of the customers network team we found out that even technically bypassing F5 was not really bypassing it because it was also being used for “in-line” traffic routing. In other words the default gateway of TMG was using a VLAN that the F5 LTM was hosting. That functionality is described here. The customer consulted their F5 expert who was able to find out there is a 300 second idle timeout enforced on that particular VLAN. Here was the smoking gun!

Conclusion:

In these types of issues always examine the data and determine if we are really seeing the whole picture. In this particular case we had to question every device in the path of the data before we ultimately found the root cause. In summary, the pain was being caused by a combination of the client device not handling resets well and a low default idle timeout set on the VLAN.

Author: Keith Abluton, Sr. Support Escalation Engineer

Problem

Running the configuration wizard on the WAP Server generates the following error:

“An error occurred when attempting to establish a trust relationship with the federation service. Error: The underlying connection was closed: An unexpected error occurred on a send.”

Figure 1 shows the error we see in the wizard.

Fig. 1

Data Gathering and Analysis

Checking the AD FS Admin event log on the WAP Server we see an Event ID 393 that corresponds to the time we received the error from the wizard (Figure 2).

Fig. 2

I also used Netmon 3.4 to capture a trace and see what was happening on the wire. Filtering the traffic for TCP traffic coming from the ADFS Server I can see the below behavior (Figure 3).

Fig. 3

As you can see there the TCP 3 way handshake sets up, there is a SSL/TLS Client Hello from the WAP Server and immediately the ADFS server resets the connection.

Since we have seen other issues that are caused by an incorrect SNI header that is the first place I checked. The SNI header value is fs.fabrikam.com (Figure 4).

Fig. 4

Back on the ADFS Server I run the command netsh http show ssl and verify that this is the correct value that is bound to port 443 (Figure 5).

Fig. 5

This issue was a little harder to diagnose than some of the previous ones we had seen. There was no corresponding event on the ADFS Server. We finally came to the conclusion that it was a protocol issue and found out that TLS 1.0 had been disabled on the WAP and ADFS Server. This has become a common practice because of some of the recent attacks such as Poodle.

Below is a summary of the values for the following key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

ADFS Server:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]

"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]

"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]

"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

"Enabled"=dword:00000000

WAP Server:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]

"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]

"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]

"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]

"DisabledByDefault"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

"Enabled"=dword:00000000

As you can see TLS 1.0 Server and Client was disabled on both machines.

Resolution

In order to get this working again we had to enable TLS 1.0 on both the WAP and ADFS Server. In particular ADFS (Server) and WAP (Client) had to be enabled. We are likely to see this more often as companies become more aware of threats and attempt to lock down protocols on servers.

Update:We realized that some people may be hesitant to use TLS 1.0 so we did some additional testing. It turns out that this is an issue with .NET Framework 4 not using TLS 1.1 or 1.2. By adding a simple registry key to the WAP Server you can get this functioning with TLS 1.0 disabled and TLS 1.1 or 1.2 enabled.

Reboot the WAP Server after adding the key and you should be good to go.

Note: If the information contained here was useful please let me know in the comments below. Also, if there are any corrections needed or you would like to see future content on a particular subject please let me know that as well. Thanks!

Special thanks to Ian Parramore for this research and troubleshooting!

Some of the more frustrating issues I come across when supporting UAG are encountered when publishing SharePoint. It seems as though SharePoint 2010 is particularly vulnerable to oddities when publishing it through UAG or any reverse proxy for that matter.  Ben Ari has a great blog that goes a long way to explaining why it can be challenging.

https://blogs.technet.com/b/ben/archive/2010/12/29/sharepoint-publishing-concepts-and-considerations.aspx

I used the concepts Ben laid out but I wanted to show you exactly what I did to solve this particular problem.

Note: In the resolution below I am making an assumption that you are using SSL on your UAG trunk to publish SharePoint. I highly recommend using SSL for security reasons.

Problem

You have SharePoint 2010 published through Unified Access Gateway 2010 but external users are unable to check out documents. Also, when choosing to Edit them they are “Read-Only”.

As you can see in Figure 1 below that the client is going to try to Check Out a document that is in the Shared Documents area.

Fig. 1

The user gets the below error which states “This document could not be checked out. You may not have permission to check out the document or it is already checked out or locked for editing by another user.” (Figure 2)

Fig. 2

You may also see an issue if you click on the document link and try to Edit it through the “Open Document” interface.  (Figure 3)

Fig. 3

The document opens up in Word or Excel but on the header bar is says “Read-Only”. (Figure 4)

Fig. 4

Resolution

To resolve this issue I have documented the exact steps I went through in my test lab.  The figure below shows the only existing Alternate Access Mappings that existed before we started steps to resolve. (Figure 5).

Fig. 5

1.) From the SharePoint 2010 Central Administration click on Manage Web Applications (Figure 6).

Fig. 6

2.) Highlight the application you are publishing through UAG and click Extend to extend the web application. (Figure 7)

Fig. 7

3.) You will need to change the port to 80 (or 443 if you are set up for SSL) and you will also set a host header. Make up something unique but remember it for later. In this case I just called it “spexternal”. (Figure 8)

Fig. 8

4.) Scroll down on this same step and set the URL to be what your external users will use to access the application from outside your company. In this case I used https://sp2010.fabrikam.com  (Figure 9)

Set your zone to one that is not already being used. In this case I used Internet. (Figure 9)

Fig. 9

5.) Go back to the main page of your SharePoint Central Administration and click on “Configure Alternate Access Mappings” (Figure 10).

Fig. 10

6.) You will notice that there is now an new AAM for the Internet Zone (Figure 11).

Fig. 11

7.) Click on the right hand side where it says Alternate Access Mapping Collection and choose “Change Alternate Access Mapping Collection”. (Figure 12)

Fig. 12

8.) Again select the application you are publishing. In this case it is SharePoint – 80 (Figure 13).

Fig. 13

9.) Now you should see the AAMs that pertain only to that application. (Figure 14). Click Add Internal URLs.

Fig. 14

10) Under the URL protocol, host and port are you will need to put the name you came up with in Step 3. In my case it was “spexternal” and since the application is published on 80 I would use “http” as the protocol. Figure 15 shows that combined it would be https://spexternal 

You also want to make sure that the Zone you chose in Step 4 is the one selected in the Zone dropdown box.

Click Save.

Fig. 15

11.) You should have something similar to Figure 16 now in your AAMs. It shows that the request that will be coming to SharePoint from the UAG Server will be https://spexternal and the URL that “Internet” users will utilize is https://sp2010.fabrikam.com

Fig. 16

12.) The last step is to edit the publishing rule on UAG to reflect the changes you made on SharePoint. In this case I went in to the “Web Servers” tab of the publishing rule and made sure that 80 is in the “HTTP Port:” field and that the “Replace the host header with the following” is checked and that it is using the name we chose in Step 3. In this case “spexternal”. (Figure 17). Click OK and then Activate in UAG and wait until it is synchronized.

Fig. 17

Congratulations! If you did everything correctly you should now be able to Checkout documents and editing them will not show “Read-Only”.

Conclusion

Publishing SharePoint 2010 can be tricky especially through UAG 2010. In this article I explained how to properly configure AAMs in SharePoint and the changes you needed to make in UAG to get certain functions working correctly for external users.

Cheers!

Note: If the information contained here was useful please let me know in the comments below. Also, if there are any corrections needed or you would like to see future content on a particular subject please let me know that as well. Thanks!

We have seen a couple of these issues this week when running the Web Application Proxy wizard to complete an install. I am pretty sure we will see quite a few more of these so I thought I would write up a quick blog on the issue.

Problem

After installing the role for Web Application Proxy you are trying to finish the configuration wizard but you encounter the below error.

“An error occurred when attempting to establish a trust relationship with the federation service. Error: The underlying connection was closed: An unexpected error occurred on a send.”

Figure 1 shows the error we see in the wizard.

Fig. 1

Data Gathering and Analysis

It was not immediately obvious what was causing this error so the first place I looked for more information was in the Event Viewer. Under the ADFS Admin events you may find an Event ID 393.  The details do not tell us much more than the error in the wizard.

Fig. 2

I wanted to see what was happening on the wire so I set up Netmon 3.4 to capture the network trace and filtered it to see the traffic destined for the IP address of the ADFS Server. In this case it was 10.0.0.5. You would also want to take a trace from the ADFS server to make sure that the traffic is truly making it there.

We can see in Figure 3 that right after the Client Hello in the trace, the ADFS Server resets the connection.

Fig. 3

Drilling down into the Client Hello packet we find an extension called “Server Name”

Fig. 4

As we can see the server name is fs.fabrikam.com

The server name in the trace was what was put in the WAP configuration wizard during the second step (Figure 5).

Fig. 5

We should compare this to the bindings in ADFS. From an administrative command prompt on the ADFS Server run the command netsh http show ssl

Figure 6 shows the results of the netsh command.

Fig. 6

As we can see the bindings to port 443 do not match what was in the Server Name of the network trace.

Resolution

When planning your ADFS infrastructure always keep in mind what you want your external users to use as the FQDN. In this case the FQDN that was intended did not actually match the Federation Service name. I was able to easily remedy this by uninstalling the ADFS role and then reconfiguring it using the intended external FQDN as the Federation Service name. In the example above I would reconfigure it as fs.fabrikam.com. The Web Application configuration wizard will then complete successfully.

Note: If the information contained here was useful please let me know in the comments below. Also, if there are any corrections needed or you would like to see future content on a particular subject please let me know that as well. Thanks!

Problem

Web proxy clients using TMG 2010 are not able to browse a certain website.  Clients using Internet Explorer would see“This page cannot be displayed” error.

Clients not using TMG 2010 as their proxy can browse the site normally.

Data Gathering and Analysis

As with most TMG issue the first place I looked is Live Logging. It’s very easy to narrow it down by querying for IP address that the client is using. Live Logging will allow me to see in real time what is being returned to TMG by the remote server and what TMG is returning to the client. It will also tell me right off the bat if TMG is Denying the request for some reason. Figure 1 below shows you what Live Logging reveals. (Note: I removed the Destination IP and the Domain name from the Request field to protect the guilty)

Fig. 1

The first thing we notice is that TMG is allowing the request but is getting back an HTTP Status Code of 301 Moved Permanently when proxying the request from the client.

I wanted to get additional information that Live Logging was not giving me so I set up Netmon 3.4 to get a trace on the wire.

Request from TMG to misbehaving website (Figure 2)

Fig. 2

Response from misbehaving website to TMG (Figure 3)

Fig. 3

Notice that we get a 301 Moved Permanently that tells us to go right back to the same place we already requested. Again, I changed the website name to protect the guilty. So the reason our web proxy client is getting the error is that the remote website throws TMG into an infinite loop of 301 redirects.

I wanted to make sure that I knew exactly how a 301 should be behaving so I consulted the Request For Comments (RFC) which in this case is RFC 2616. These are extremely dry and not a lot of fun to read but they tell you what you should expect.

https://tools.ietf.org/html/rfc2616 (Figure 4)

Fig. 4

So there is nothing in the RFC that says the new permanent URI cannot be the same as what you already requested. Obviously we get a very undesired behavior when this is the case.

Since a client that is not using TMG as the proxy obviously behaves differently I wanted to compare the two to see what is different. Figure 5 shows the GET request from a client that is not using TMG as a proxy.

Fig. 5

In this case we get an immediate Status Code of 200 OK which is what we would expect (Figure 6).

Fig. 6

Based on what I was seeing in the Netmon tracing I suspected that the misbehaving remote website was responding with a 301 Moved Permanently in response to something it was or wasn’t getting in the initial GET request. Comparing the requests from both client traces I determined that there were 2 major differences.

1. ) TMG sends a VIA header when making the request for a web proxy client. Clients not using a proxy do not send this header when making a request.

2.) Clients not using TMG as their proxy send an Accept-Encoding header with a value of gzip, deflate. When TMG sends a GET request on behalf of a web proxy client it is not including the Accept-Encoding header.

Using a client in my test lab that could go directly to the Internet without having to use a proxy I wanted to test 2 things. I wanted to add a VIA header although the client was not using a proxy and I also wanted to strip the Accept-Encoding header out of the request.  Luckily there is a tool called Fiddler by Telerik that will allow you to do just that.

Fiddler is a great debugging tool that we use pretty frequently to troubleshoot web related issue.

https://www.telerik.com/fiddler

Adding a VIA header to the request made no difference whatsoever, the web page loaded just fine. Stripping the Accept-Encoding: gzip, deflate header from the request, however, caused the remote website to behave with the 301 Moved Permanently infinite looping.

Customers usually want to know whose product is at fault in cases like this. For that I always go back to the RFC. If your product is following the RFC to the letter then it is pretty clear that the remote website is at fault. In this case there is nothing in the RFC that states that an Accept-Encoding header MUST be sent.

I was never able to get a response from the web admins at the remote offending website to find out exactly why their Apache server is behaving this way. The RFC is not specific and does not state that they CANNOT do what they are doing but it is just very odd and pretty unexpected.

In the end I was able to find a setting in TMG that would force it to send the Accept-Encoding: gzip header which apparently makes the remote site happy. This is accomplished in the TMG MMC, under Web Access Policy, then click HTTP Compression. If you add the remote site under the “Request Compressed Data” tab then it will actually send that header.

Conclusion

As in so many of the cases that we work here at Microsoft the answer is not always readily apparent. Sometimes you have to dig pretty deep and employ multiple tools to arrive at your answer. In this case I had to use no less than 3 tools (Live Logging, Netmon 3.4, Fiddler) and the RFC as a resource to find an acceptable solution for our customer.  I hope that you enjoyed this article and it helps you to realize that troubleshooting can be a fun process especially when you use all of the tools at your disposal.

Cheers!

Note: If the information contained here was useful please let me know in the comments below. Also, if there are any corrections needed or you would like to see future content on a particular subject please let me know that as well. Thanks!

Part 1 Creating a Test Lab for Free in Azure

Part 2  Configuring Your First VM in Azure

In Part 2 of the series I walked you through creating your first VM in Azure and we gave it the Active Directory Domain Services role and it is the only Domain Controller in your new domain. In this article I will walk you through installing Active Directory Certificate Services on your DC, installing a new server that will be your Active Directory Federation Services Server, and installing a third server that will hold the Web Application Proxy (WAP) role. Once those are complete we will publish the IIS Server that is running on your Domain Controller. External clients will be able to access it through WAP.

Install the Active Directory Certificate Services Role on your DC

The reason for doing this is twofold . First, certificates are required for some of the aspects of the lab. The second reason is that doing this will also install Internet Information Server (IIS) on your domain controller which we will publish to the outside world with WAP.

To get started installing Active Directory Certificate Services:

1. Log in to the Azure Management Portal at https://manage.windowsazure.com

2. Choose your domain controller and from the Dashboard click on  “Connect”. Log in to the RDP session with your Administrator credentials.

3. In Server Manager launch the “Add Roles and Features” Wizard.

4. Choose to do a “Role-based or feature-based installation.”

5. Select the DC in the Server Selection dialog.

6.) Choose “Active Directory Certificate Services” and click “Next.”

7.) Click “Add Features.”

8. Click “Next.”

9. Click “Next.”

10. Again click “Next.”

11. At Select Role Services choose “Certification Authority” and “Certification Authority Web Enrollment.”

12. Click “Next.”

13. Accept the defaults and click “Next”

14. At the confirmation click “Install.”

15. After the installation has succeeded click on the message “Configuration required.”

16. Specify the credentials that will be used.

17. Click “Next.”

18. Choose “Enterprise CA.”

19. Choose “Root CA.”

20. Choose to “Create a new private key.”

21. Accept the default cryptographic options and click “Next.”

22. Leave whatever is the default at “Specify the name of the CA.”

23. Leave it at a 5 year validity period and click “Next.”

24. Accept default locations for CA Database and click “Next.”

25. At Confirmation screen click “Configure.”

26. After you are notified that the roles were successfully installed click “Close.”

Creating a Certificate Template

Now that you have ADCS installed we will need to create a Certificate Template that will allow Computers to request a new certificate and allow the Private Key to be exported.

To do this you will need to:

1. Launch the Certification Authority management console from your Administrative Tools group.

2. Highlight Certificate Templates and right-click, then choose “Manage.”

3. Highlight the Web Server template, right-click and then choose “Duplicate Template.”

4. On the General tab give you template a name meaningful to you.

5. On the Request Handling tab check the “Allow private key to be exported” box.

6. Under the Security tab add Domain Computers and Domain Controllers and then make sure they have the Enroll ability and then click “Apply.”

7. Highlight Certificate Templates, right-click on it and choose New, then “Certificate Template to Issue.”

8. Choose the template you configured earlier and click “OK.”

9. Open an MMC and add the Certificate snap-in. Click “OK.”

10. Choose “Computer Account.”

11. Select the Local computer and click “Finish”, then “OK.”

12. Expand the Personal branch and highlight Certificates, right-click on “All Tasks”, then “Request New” Certificate.

13. The Certificate Enrollment Wizard will launch. Click “Next.”

14. Highlight Active Directory Enrollment Policy and click “Next.”

15. Check the box next to the template you configured and then click on the “More information is required to enroll for this certificate.”

16. On the Subject Tab click on the Type dropdown box and choose Common Name and under value put in a wildcard asterisk followed by your domain name. So mine would be *.fabrikam.com and then click “Add.”

17. Click “Apply.”

18. Now click “Enroll.”

19. You should get a message that is succeeded.

20. You should now have a Wildcard certificate for your domain installed in your Certificate Store and you will be able to export that certificate with the private key when we need it later.

Create and Configure Your ADFS Server

I will assume that you are somewhat familiar with creating a machine and that you followed Part 2 of this series.

To get started creating the ADFS Server:

1. While logged in to the Azure Management Portal click on “Virtual Machines” and then create a new Virtual Machine.

2. From the Gallery pick Windows Server 2012 R2 Datacenter as the image you will use.

3. Under the “Virtual Machine Configuration” menu choose your name, the Tier you will be using, the size of the VM, the name you used as administrator when you configured your DC, and the password.

4. Choose your existing cloud service (needs to be the same one where you DC is located) and use the same Storage Account which was used for your DC.

5. Provision the machine and wait until the status in the portal says “Running.”

6. Connect to the new machine and log in with your administrator credentials.

7. I found the easiest way to add the computer to the domain is to open PowerShell as an Administrator and use the command Add-Computer –DomainName fabrikam.com   (Note: If you did not use fabrikam.com as your domain substitute your own domain name in).

8. You will be prompted for your domain admin credentials and then you will need to restart after it is completed.

9. After the machine has been restarted it is now a member of the domain and we will add the Active Directory Federation Services role using the Add Roles and Features Wizard.

10. Click Next at every choice and just accept all the defaults.

11. After feature is installed you will need to configure the service.

12. Before finalizing the configuration of the ADFS role you should request a certificate that will be used by ADFS.

13. Open an MMC and add the Certificates Snap-in (Local Computer).

14. Expand the Personal branch and right-click on “Certificates”, choose “All Tasks”, then “Request New Certificate.”

15. This will start the Certificate Enrollment Wizard. Click “Next”, leave the Active Directory Enrollment Policy selected and click “Next”.

16. Put a check next to WebServer(PrivateKeyExportable) which was the template you created earlier. You will then need to click on the “More information is required to enroll for this certificate. Click here to configure settings.”

17. Under the Type drop down box choose common name, type in whatever you want to call your Federation Server. You can use the actual server name or deviate from that. I chose fs.fabrikam.com. Click “Add.”

18. Your new CN will appear on the right hand side and then click “Apply.”

19. Enrollment should succeed and you should now see the certificate you requested in your Personal Certificates branch.

20. Go back to your Add Roles and Feature Wizard and click on “Configure the federation service on this server” . This will start the Active Directory Federation Services Configuration Wizard. Leave “Create the first federation server in a federation server farm” as the choice and click “Next.”

21. At the next step just specify the current user as the account you want to use to perform the federation service configuration. Click “Next.”

22. You will now choose the certificate you created earlier, give your Federation Service a name, give it a Display Name, and choose “Next.”

23. The next step will let you know that Group Managed Service Accounts are not available because the KDS Root Key has not been set. It will give you the PowerShell command that you need to run. Click OK to acknowledge it.

24. Open an Administrator PowerShell Command window and then run the command.

25. Now specify the Group Managed Service Account that you want created and click “Next.”

26. Leave the choice “Create a database on this server using Windows Internal Database” and click “Next.”

27. At the Review Options screen click “Next.”

28. Assuming you did everything correctly you should get a message that All Prerequisites checks passed. Click “Configure.”

29. You should get a Results screen that tells you “This server was successfully configured”. Click “Close.”

Congratulations! You now have an ADFS Server in your Azure test lab.

Create and Configure Your Web Application Proxy Server

Again I will assume at this point that you are familiar with creating a new virtual machine in Azure. In your Azure Management Portal create a new virtual machine that will be your WAP Server. After it has been created you will need to connect to it via RDP.

To get started creating the Web Application Server:

1.) Add your new server to the domain and reboot it.

2.) Export the wildcard certificate you created earlier on your Domain Controller and copy the file over to your new WAP Server. Import the wildcard certificate into the Certificate Store (Local Computer) under the Personal Certificates branch.

3.) Start the Add Roles and Features Wizard on the WAP Server. Once you get to the Server Roles section put a check box next to Remote Access and click “Next.”

4. Click “Next” at the Select Features screen.

5. Click “Next.”

6. At the Select Role Services put a check box next to Web Application Proxy and click “Next.”

7. Click “Add Features.”

8. Click “Next.”

9. Click “Install.”

10. After the install succeeds you will need to click “Open the Web Application Proxy Wizard” to finish the configuration.

11. Click “Next” at the Welcome screen.

12. Select your Federation Service Name and credentials. (Note:  Since my federation service names differs from the actual name of the ADFS server, I had to either add a HOSTS name entry or create a CNAME in DNS so that the WAP Server knows how to resolve the FQDN of  fs.fabrikam.com ).

13. Now we select the wildcard certificate that was imported earlier and click “Next”.

14. The next screen will show you the PowerShell command that will be run under the covers. Click “Configure.”

15. If all went right you should get a message that the configuration was successful. Click “Close.”

Congratulations! Web Application Proxy is now installed on your server.

Configuring WAP to Publish Your First Application

We are now going to configure your WAP Server to publish IIS which is running on your Domain Controller. This is just a very basic rule but demonstrates how to publish something from your Azure virtual machine domain to the outside world.

1. From your Administrative Tools program group double-click on Remote Access Management.

2. Click “Next” at the Welcome screen.

3. Choose “Pass-through” as the authentication method and click “Next.”

4. Call it anything you like in the Name dialog. The External URL will be what external clients type into their browser to access the application and should be prefaced by HTTPS. Choose the Wildcard certificate you imported previously. The Backend Server URL will be used by WAP to proxy the request. In the lab we created this should be the FQDN of your domain controller prefaced by HTTP. So in my case it is http:\\dc1.fabrikam.com. You will get a Warning at the top but just ignore it. Click “Next”.

5. At the Confirmation screen click “Publish.”

6. If all went right you should get a message that your application was published successfully. You can close the wizard.

7. You should see your application listed in the Remote Access Management console.

Allowing Access From the Outside World

Before you can actually access your published application externally you will need to create an Endpoint in Azure to allow the HTTPS traffic to be forwarded to your WAP Server.

1. To do this go to your Azure Management Portal, highlight your WAP virtual machine, and click on “Endpoints” at the top.

2. Azure will show you what you currently have in the way of service endpoints. You will notice that PowerShell is there and so is Remote Desktop. Click “Add (+)” at the bottom of the screen.

3. Choose to “Add a Stand-Alone Endpoint” and then click the arrow in the bottom right hand corner to move to the next screen.

4. In the drop down box for Name choose HTTPS and Protocol TCP. Public and Private Port will both be 443. Click the checkbox to complete.

5. Your endpoints will be updated and should reflect the change.

Accessing From An External Client

The final step will be testing access from a client not located in Azure. You will need to add an entry to your clients HOSTS file so that it will be able to resolve the FQDN of both your Domain Controller and your Federation Service Name correctly. You can find the IP address that will be used in the hosts file by clicking on your Virtual Machines Dashboard and looking along the right hand column. There will be an IP address underneath the Public Virtual IP (VIP) Address section. So in my case I added host entries for fs.fabrikam.com and dc1.fabrikam.com to resolve to my Public IP. (Note: Since no authentication is being done at this time the fs.fabrikam.com entry  is not really needed but I am putting it in there for future applications that will need it.)

Once that is done you can test access to your IIS Server. (Note: You will get a warning about not trusting the certificate and that is to be expected unless you install the Root CA from your DC in the certificate store on your client. You can safely ignore it and choose to continue.)

If you have done everything right you should see the IIS landing page.

Conclusion

I know I have covered a lot in this article and I hope it was valuable to you. Many of you may not have needed the detailed screenshots but I wanted to include them for those that did. I will be continuing this series by building out other machines that will be needed in typical test labs. Please keep in mind that you pay for what you use in Azure. To minimize my costs I only leave my Domain Controller running when I am not actively testing or troubleshooting. By shutting down your other machines through the Azure Management Portal you will not be incurring expenses for them while they sit idle.

Cheers!

Note: If the information contained here was useful please let me know in the comments below. Also, if there are any corrections needed or you would like to see future content on a particular subject please let me know that as well. Thanks!