Re: Shared Certificate Store in Active Directory
From: David Cross [MS] (dcross_at_online.microsoft.com)
Date: 01/12/04
- Next message: THOMAS: "EVERYONE removed from security - system will not boot"
- Previous message: Cameron: "Firewall Device Recommendations"
- In reply to: Steve Buckley: "Re: Shared Certificate Store in Active Directory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 11 Jan 2004 20:05:54 -0800
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] -- This posting is provided "AS IS" with no warranties, and confers no rights. http://support.microsoft.com "Steve Buckley" <SBuckley@cybernetgroup.com> wrote in message news:052101c3d1a1$175174e0$a101280a@phx.gbl... > 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. > > >-----Original Message----- > >Some answers and observations inline... > >Brian > > > >In article <017d01c3cccb$35731df0$a401280a@phx.gbl>, > >anonymous@discussions.microsoft.com says... > >> 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 security@example.com, US, > WA, Redmond, > >Example, Corporate, Issuing CA > >Root Certificate Authority security@example.com, 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 > >> > >> >-----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. > >. > >
- Next message: THOMAS: "EVERYONE removed from security - system will not boot"
- Previous message: Cameron: "Firewall Device Recommendations"
- In reply to: Steve Buckley: "Re: Shared Certificate Store in Active Directory"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
