Shared Certificate Store in Active Directory

[Steve Buckley]

WARNING - This question is not as easy as it may first
seem, this is a repost of a question originally asked in
the Active Directory forum.

How do you configure a "Shared Certificate Store" in
Active Directory so you can make Certificates and their
associated Public Keys available to members of the
Enterprise, for example to enable IPSec encryption using
Certificates rather than Kerberos?

They are clearly stored *somewhere* already as they are
visible against the user/machine accounts in the Active
Directory Users & Computers MMC.
The CDP container only contains the CRL object - where is
the actual store and how do you set permissions on it?
Or do you have to create one somehow?

I have been puzzeling over this one for a good 6 months -
if someone comes back to me with click on "Allow
certificates to be published in Active Directory" I'll
slap them for not reading my question.
..

The answer to this question does not appear to be in any
of the Microsoft Security MCSE core texts or Technet.

 

[David Cross [MS]]

There is no need to store IPSEC certs in the AD for IPSEC, the certs are
exchanged as part of the IKE negotiation. Same thing for SSL/TLS. The
case where a lokkup is needed is when encryption is used such as in S/MIME.
IN that case the certificate is stored on the user object on an attribute
known as userCertificate.

 

[Steve BUckley]

An interesting observation and is how I originally
figured it worked, however it appears to not be entirely
the case, how do you set up a "Shared Certificate Store",
is the error a bug in the group policy object?
It would make sense to have a shared store so
applications can directly access Certificates & Public
Keys that are trusted/validated through AD and if you try
to enforce Certificates Based Encryption via Group Policy
using the Local Security Policy keys you are warned:
******************************************************
Warning!
The Active Directory does not contain a shared
certificate store.

When configuring Active Directory based IPSec policy to
use certificate authentication the administrator must
ensure that each domain member has an appropriate
certificate installed.

Do you want to select a certificate authority from the
local machine certificate store?
********************************************************
There is also the option in the Output Module of the
Cetificate server to publish in Active Directory, however
checking this box "appears" to not do anything - maybe it
just associates the certificate with the user object, but
then again it does this without the box ticked as well.
What is you interpretation of the above error/warning
message?

-----Original Message-----
There is no need to store IPSEC certs in the AD for IPSEC, the certs are
exchanged as part of the IKE negotiation. Same thing for SSL/TLS. The
case where a lokkup is needed is when encryption is used such as in S/MIME.
IN that case the certificate is stored on the user object on an attribute
known as userCertificate.

--


David B. Cross [MS]

--
This posting is provided "AS IS" with no warranties, and confers no rights.

http://support.microsoft.com

WARNING - This question is not as easy as it may first
seem, this is a repost of a question originally asked in
the Active Directory forum.

How do you configure a "Shared Certificate Store" in
Active Directory so you can make Certificates and their
associated Public Keys available to members of the
Enterprise, for example to enable IPSec encryption using
Certificates rather than Kerberos?

They are clearly stored *somewhere* already as they are
visible against the user/machine accounts in the Active
Directory Users & Computers MMC.
The CDP container only contains the CRL object - where is
the actual store and how do you set permissions on it?
Or do you have to create one somehow?

I have been puzzeling over this one for a good 6 months -
if someone comes back to me with click on "Allow
certificates to be published in Active Directory" I'll
slap them for not reading my question.
.

The answer to this question does not appear to be in any
of the Microsoft Security MCSE core texts or Technet.

.

 

[Brian Komar]

Some answers and observations inline...
Brian

An interesting observation and is how I originally
figured it worked, however it appears to not be entirely
the case, how do you set up a "Shared Certificate Store",
is the error a bug in the group policy object?
It would make sense to have a shared store so
applications can directly access Certificates & Public
Keys that are trusted/validated through AD and if you try
to enforce Certificates Based Encryption via Group Policy
using the Local Security Policy keys you are warned:
******************************************************

The concept of certificate trust is based on a system of trusted root
CAs, rather than designating specific certificates as trusted. As long
as the certificate chains to a trusted root CA, then the certificate is
deemed trustworthy. For MS's IPSEc implementation, both end-point
certificates must chain to the *same* trusted root.

Warning!
The Active Directory does not contain a shared
certificate store.

When configuring Active Directory based IPSec policy to
use certificate authentication the administrator must
ensure that each domain member has an appropriate
certificate installed.

Remember that the domain members are the computer accounts, not the user
accounts.

Do you want to select a certificate authority from the
local machine certificate store?
********************************************************
There is also the option in the Output Module of the
Cetificate server to publish in Active Directory, however
checking this box "appears" to not do anything - maybe it
just associates the certificate with the user object, but
then again it does this without the box ticked as well.
What is you interpretation of the above error/warning
message?

The certificate would be associated with the computer account, not the
user account. In the MS implementation, the IPSec security association
is between the two computer accounts, the user just happens to be
sitting at one of the two computers (in the case of transport mode).

The message is stating that you *must* select a certificate that is
assigned to the computer account for certificate-based authentication.

When IPSec uses certificate-based auth, the oakley log, if enabled, will
show the successful authn.

4-18: 13:26:12:144 Setting SA timeout: 25920
4-18: 13:26:12:144 constructing ISAKMP Header
4-18: 13:26:12:144 constructing ID
4-18: 13:26:12:144 Cert Trustes. 0 100
4-18: 13:26:12:144 Key Contained Name
4-18: 13:26:12:144 555f7cd43b035f7c2f61fede13ef2512_6a2027a5-bb79-4adf-
a835-2f6574d41ec5
4-18: 13:26:12:144 Found try 1
4-18: 13:26:12:144 Keylen in cert 512
4-18: 13:26:12:144 Entered CRL check
4-18: 13:26:12:144 Left CRL check
4-18: 13:26:12:144 Creating PKCS7 wrapped x509 cert
4-18: 13:26:12:144 Cert lifetime in seconds low 31444211, high 0
4-18: 13:26:12:144 constructing CERT
4-18: 13:26:12:144 constructing SIG
4-18: 13:26:12:144 Construct SIG
4-18: 13:26:12:144 Hash algo 1
4-18: 13:26:12:144 Error 80090016 during CryptSignHash1!

4-18: 13:26:12:144 Trying KE key
4-18: 13:26:12:144 Signature Created Successfully
4-18: 13:26:12:144 In state OAK_MM_KEY_AUTH
4-18: 13:26:12:144 Key Exchange Mode (Main Mode)

4-18: 13:26:12:144 Certificate based Identity.
Subject triplesec.ipsecca.example.com
Issuing Certificate Authority (e-mail address removed), US, WA, Redmond,
Example, Corporate, Issuing CA
Root Certificate Authority (e-mail address removed), US, WA, Redmond,
Example, Corporate, Issuing CA
Peer IP Address: 128.5.1.2

The big thing is that you do not have to have the certificate published
in AD. When IPSec negotiates the security association, the certificate
is only used to authenticate the endpoints. The only reason that you
would ever publish a signing certificate (authentication purpose only)
is when you wish to prevent an entity from enrolling multiple versions
of the same certificate from multiple computers. The publication in the
AD will allow you to prevent enrollment if a certificate already exists
in the userCertificate attribute.

Brian

 

[Steve Buckley]

I appriciate your time and effort - unfortunately you
have managed to waffle on quite a bit telling me a lot of
stuff I already know whilst managing to not comprehend
let alone actually answer the question - "How Do You
Configure A Shared Certificate Store in AD?"
In future read a question before you answer it, it takes
a special kind of stupid to actaully cut and paste the
same warning message 3 times into a post and make
comments on it without actually reading it.

Warning!
The Active Directory does not contain a shared
certificate store.

When configuring Active Directory based IPSec policy to
use certificate authentication the administrator must
ensure that each domain member has an appropriate
certificate installed.

CAN YOU READ THE ABOVE AND WHAT DO YOU THINK IT MEANS?

If you have never seen this message then you have
probably never tried to deploy Certificates based IPSec
through Active Directory Group Policy.

 

[David Cross [MS]]

I am not clear on what the open question is; can you please re-state in a
new thread? Users can lookup other user certs in AD, but they do not share
the same certificate across users.

--


David B. Cross [MS]