Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

WebDav client transparent authentication

If you use the built-in WebDav client in Windows from a domain joined Windows 7 client, you may want to be able to establish a logical drive to a domain joined IIS/WebDav server.

You would for example try

net use * https://<server>.<domain>.net/files

You will be prompted for username and password and get your logical drive if everything has been set up correctly.

Often, if you use WebDav in a domain joined environment, you may prefer to have the logical drive mapped without having to type in your username and password.

You can edit the registry to configure for which domains, the current credentials can be forwarded from the WebDav client.

HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
Insert a new key, REG_MULTI_SZ  “AuthForwardServerList

Examples using this key is shown below

https://*.domain.net
https://*.Contoso.com
http://*.dns.live.com
*.microsoft.com
https://172.169.4.6

Se more in http://support.microsoft.com/kb/943280 

After you make the change and restart the WebClient Service, you should be able to map a WebDav drive without being prompted.

Initial manual enrollment with auto-enrollment/renewal applied afterwards

When you have a server that needs a server certificate with special needs, like a subject name that is different from the server name, we typically accept to do the enrollment manually. Also we are used to accept to renew the certificate manually, when it expires.

Using Windows Server 2008 R2, we may not need to manage the renewal manually. In the CA MMC, you have the choice to use existing certificate for later renewals. This is the option, we are interested in. Se the figure below.

Even so you use this setting on a template and enroll a certificate manually by specifying a given subject name and expect the renewals to work automatically afterwards, it requires that your applications using the certificate is able to automatically use the updated certificate. IIS is an example of one such application that is able to do that as it uses the SChannel API.

Web Services Enrollment for non-domain joined clients

As you may have noticed, Windows Sever 2008 R2 PKI has support for Web Services enrollment, meaning that you can have auto-enrollment working using HTTP(S) as opposed to using DCOM/RPC. This is especially interesting, when the client is in another security zone with various firewall in between or when enrolling across the Internet.

If you have clients that are non-domain joined to the internal domain, I noticed an interesting use-case of using Web Services enrollment. The scenario is the following:

• You accept to manually enroll the client using HTTPS web services interface and providing credentials to get enrolled
• You configure the web services enrollment to accept an existing certificate as authentication on the Web Services enrollment server. This means that the auto-enrollment can renew the certificate automatically after initial manual enrollment by using the existing certificate as authentication mechanism.

One example where this may be useful is where you have remote servers in a separate domain or forest that you need to manage using SCOM and/or SCCM. In this case you could issue certificates to these servers from your PKI infrastructure and have them being updated using auto-enrollment, meaning less management/administration on the remote servers. This however only means that you will get the computer certificates on the remote server updated automatically. Whether or not the application is able to see the renewed certificate depends on the application. Applications using SChannel API (such as IIS 7.5) will be able to automatically use the renewed certificate, whereas others applications many need further manual configuration to use the new certificate.

Notice that the clients also need to be Windows Server 2008 (or Windows 7).

WebDav client authentication

If you want a secure file transfer solution over the Internet to your corporate office, you could consider using WebDav over SSL.

IIS 7.5 has built-in support for both FTPS and WebDav.

Using FTPS seem to be a logical choice. However this solution has some challenges

• It is difficult to handle various address translations between source and destination.
• Content inspection at the perimeter level is difficult if not impossible using FTPS. TMG and ISA as well as UAG does not support FTPS content inspection at the gateway level.
• Pre-authentication impossible at the perimeter/gateway level. As you can’t terminate the SSL on the gateway level, you need to bypass it to the FTPS server without doing pre-authentication.
• Firewalls may not allow the ports used by FTPS.

Using WebDav in 7.5, you can do all these things, for example on a TMG, so that the flow is

External WebDav Client->@Internet->Border Router->FW->Load balancer->TMG->Internal WebDav server(s)

On top of using WebDav, you could consider using client certificates as authentication, for example if you are dealing with external clients (or servers) not belonging to your domain, and if you want to have a persistent inbound connection from the external locations to your internal WebDav server in a secure manner without having go administer usernames and passwords.

Remember, however that the built-in WebDav clients in Windows OS does not have support for Client Authentication, so you need to use a commercial product like WebDrive or develop a client yourself using .NET framework.

Using client certificates, you can now connect to TMG and convert the certificate on the TMG to internal Windows Credentials between TMG and the WebDav server. This requires setting TMG up to use KDC (Kerberos Constrained Delegation) and protocol transitioning, especially if you have your files stored on a backend file server where you need to keep the identity of the client connecting.

The enrollment of the client certificate from the remote location (over the Internet), can be done using FIM-CM.

Number of FIM-CM Instances in one forest

 

In some customer scenarios, we have had a need of being able to install multiple FIM-CM instances in one forest with multiple PKI solutions. Some documentation like the new IPD guide for FIM 2010 indicates that you can only have one instance per forest. However after having researched this a bit internally, I was informed that there should be no problem in having multiple separate FIM-CM instances in one forest and that it is fully supported.

FIM-CM certificates protected by SafeNet HSM

Forefront Identity Manager, Certificate Manager requires three certificates for infrastructure purposes. They are

• FIM CM Agent certificate
• FIM CM Enrollment Certificate
• FIM CM Key Recovery Agent Certificate

The certificates are rather sensitive and it makes sense to protect the private keys for these certificates on a HSM.

I have been using SafeNet HSM to protect these certificates and ran into a problem with the FIM-CM Agent certificate.

The requirement for the FIM-CM Agent certificate is that the CSP must support AES. Also FIM-CM does not support version 3 certificate templates, so it must be a CSP that is used by a version 2 template.

A software based Microsoft CSP is available that supports this. However when the private key must be protected by the HSM, the requirement is that the HSM vendor has a CSP that supports this requirement.

SafeNet supplies both a CNG based driver (64-bit KSP module) and a 32-bit and 64 bit CSP module.

As FIM-CM does not support a version 3 template that supports CNG, we are forced to using the CSP module from SafeNet. The question was then whether or not this CSP supports AES. SafeNet support was not sure about this, so I chose to test it out. The conclusion was that the 64-bit SafeNet CSP driver does not support AES and therefore FIM-CM failed with errors. This can be verified by setting the tracing level for Microsoft.Clm.BusinessLayer.Encryption to 4 in Web.config. The c:\temp\clm.txt now shows that there indeed are problems with the AES decryption.

One of my colleagues in Microsoft suggested that I changed FIM-CM to use TripleDes instead of AES. This can be done by changing the following line in web.config.

<!– One of the following: Aes, Des, TripleDes –>
<add key="Clm.Encryption.Algorithm" value="Aes" />

I chose to try TripleDes, and after that I issued a new FIM-CM Agent certificate and tried enrolling a certificate again from the FIM-CM portal. This time it worked, so now I have all three FIM-CM certificates protected by the HSM module, which is nice.

It is more secure, and I have the backup of the private keys covered by an existing backup procedure for the HSM modules, so I don’t have to make the FIM-CM private keys exportable and make explicit backups.

Citrix on Windows Mobile using client certificate

In a customer case, we are investigating how a Windows Mobile PDA can be used to access applications on the Intranet environment on wireless network through Citrix.

The PDAs are running Windows Mobile 6.1. We are using XenApp Plugin version 10.x and 11.x on the PDA. The Citrix environment is Xen Web Interface version 5.2 and XenApp Servers.

 

Currently we can get the the PDAs connected to the wireless network using EAP-TLS with WPA2. Also we can access the Xen Web Interface and see published applications without any username/password prompt, as the certificate is being used to authenticate to the Web Interface service. However when we access any Citrix applictions published, we are required to provide credentials.

 

Citrix/XenApp servers have the ability to use Smartcards as authentication mechanism. In this setup we don’t use a physical smartcard, only software based certificates on the PDAs. The certs have been created with the following certificate types: Client authentication and Smartcard Logon. We are hoping to get it to work as we would then be able to provide a more friendly user experience with enhanced security as opposed to having the user typing username/password in manually each time or optionally store the username/password in the Citrix client on the PDA (not possible for all versions).

 

I will update the entry, when we have a conclusion on how to get it working. Citrix support is involved. One of the things that are a bit unclear when using certifcates to authenticate to the Citrix environment is what the requirements are to Kerberos delegation. Normally Kerberos delegation would require the IIS web server to be configured using constrained delegation together with protocol transitioning, but that does not seem to be required when using Smartcard logon in the Citrix environment.

WMDC certificate enrollment method

Windows Mobile Device Manager on Vista and Windows 7 can be used to manage Windows Mobile devices.

One nice feature of WMDC is its ability to be used to enroll a client certificate on a Windows Mobile device that you have paired with the PC.

A few things to note about using WMDC for certificate enrollment

 

1) Requires WEB enrollment enabled on the CA server that is being used to enroll from

2) IIS on the CA server must have integrated windows authentication integrated as web enrollment using WMDC requires at least NTLM. It does not work with basic authentication.

3) You can enroll a certificate to a PDA using a domain account that is different from you currently logged in account. You don’t need to log out and log in with the account that should have the certificate. This is nice if you are a supporter and needs to enroll several PDAs with different certificates/users. Notice that if a supporter is delegated the right to enroll on behalf on another user, it means that the supporter knows the password of the user. Therefore in some organizations this is not acceptable seen from a security point of view.

4) You need to pair the PC with the PDA before you can choose to enroll a certificate to the PDA.

5) The private key of the users certificate is transferred securely directly to the PDA through the PC’s domain membership. The private key is never out in the free as it would be, if you chose to install the certificate using a .pfx file as opposed to online enrollment.

6) As you are forced to use Windows authentication to enroll for the certificate, you don’t have to enforce SSL between PC and CA server on the Web protocol, even so it would be considered even more secure and a best practice to do.

 

FIM-CM 2010 – ECAL tip (License TIP)

The license model of FIM-CM 2010 as part of Forefront Identity Manager 2010 dictates that any certificate "managed" by FIM-CM requires a separate Client Access License (CAL). So if you have an Issuing CA that is being used to auto-enroll 15.000 PC using Wireless network without FIM-CM being involved and 100 S/MIME Encryption certificates being handled by FIM-CM, the question is how many CALs you need to follow the license requirements of FIM-CM.

 

FIM-CM installs a FIM-CM agent on each Issuing CA that enrolls certificates that must be handled by FIM-CM. So if you have one Issuing CA as described above, you would think that you only need 100 CALs for the S/MIME certificates. Now, – the FIM-CM agent includes a policy module as well as an exit module and the exit module writes a record to the FIM-CM database for any certificate enrollment on the Issuing CA, even so it is a request for a certificate the is not handled by FIM-CM. So the FIM-CM database keeps a record of all issued certificates, meaning for all 15.100 certificates. Does this mean that FIM-CM "manages" all these certificates and that you need 15.100 CALs?

 

The answer is NO, you only need 100 CALs.

 

If you don’t want to have records in FIM-CM of certificates that are not managed by FIM-CM, you should consider to have separate Issuing CAs that only issue certificates that are managed by FIM-CM. The downside of this is of course, that you then need more Issuing CAs.

 

Remember that if FIM-CM is being used to handle encryption certificates, there must be a 1-1 relation between the FIM-CM server and the Issuing CA in order for recovery to take place. This makes it a bit more challenging to make fail-over for certificates that are being used for encryption purposes. This means that even so you may have multiple Issuing CAs that issue encryption certificates, you may have a single point of failure when talking about the recovery scenrio (as opposed to the enrollment scenario, where multiple CAs may be able to serve the request.