"Ron Lowe" <ron-msng@{d.e.l.e.t.e}lowe-family.me.uk> wrote in
news:(E-Mail Removed):
> Hi all.
>
> I've got what I think is an autoenrolment problem which is eating my
> lunch. The IAS machine / DC deletes a manually requested cert, but I
> can't get it to Auto Enroll one either.
> I'm not much expert at PKI stuff :-)
>
> Observer Problem:
> =============
> Wireless clients became unable to connect using EAP-TLS, unable to
> verify the IAS server cert.
> Disabling 'verify server cert' on the clients provides a workaround.
>
> Environment:
> =========
> There is one forest, containing one domain, with one server.
> The server is Domain Controller, Certificate Authority, and IAS.
> The CA is mainly to provide certs for wireless EAP.
> ( Windows Server 2003 SP1 )
>
> Investigation:
> =========
> Server event log shows IAS complaining that the cert object no longer
> exists.
> Sure enough, in the 'Certificates - Local Machine MMC' snap in, the
> Domain Controller cert has disappeared!
> IAS then appears to have 'made up' a cert which is of no value.
> ( I can see the CA root cert, and a couple of certs issued by the CA:
> Domain Controller Authentication, and E-mail replication. Then there
> is this machine cert issued to 'servername', but issued by
> 'servername', not the CA. This is no good to man nor beast. )
>
> Things I've Tried:
> =============
> I can manually request a cert, type = Domain Controller.
> This works OK.
> I see the cert being issued by the CA, and it appears in the Local
> Machine store.
> Within IAS -> configure EAP, I can select and use this cert, and
> everything works again.
> Only the cert disappears out of the cert store after a random period
> of time!
> Sometimes an hour, sometimes overnight.
> There's nothing in the event log which shows what has happened.
> Just IAS screaming blue murder about the cert disappearing.
>
> This article says that Auto Enrolment must be used to grant a DC cert:
> http://www.microsoft.com/technet/pro...r2003/library/
> ServerHelp/43881ad5-aa6b-4527-ad59-cd2218bd9934.mspx So perhaps
> auto-enrolment is deleting my manually requested cert?
>
> I think I have auto-enrolment correctly configured, but I may be
> wrong: Using GPMC, here's my settings:
>
> Default Domain Controller Policy
> Computer Configuration (enabled)
> Windows Settings
> Security Settings
> Public Key Policies / Autoenrolment
> Enroll Certs Automatically: Enabled
> Renew Expired, update.., remove.., : Enabled
> Update certs that use templates : Enabled
> Public Key Policies / Automatic Cert Request Settings
> Automatic Cert Request
> Computer
> Domain Controller
> Enrollment Agent ( computer )
>
> I've just tried adding things in here to see if it helps :-)
>
> Why won't the machine auto-enroll a DC cert?
> What more do I need to do?
>
> And why did it auto-enroll the certs I didn't ask for?
> ( Domain Controller Authentication ( as opposed to Domain
> Controller )
> and E-mail replication: IAS won't recognise either of these as
> good for
> EAP. )
>
>
> I've torn down and re-installed the CA a couple of times.
> I cleaned up AD of old CAs before re-installing using this procedure:
> http://support.microsoft.com/default...b;en-us;555151
>
>
> A couple of notes:
> =============
> The CA is registered in AD. The menu option to do this was not
> initially present for some odd reason, but it seemed to register
> itself anyway, because it was listed in AD Sites and Services. The
> option re-appeared magically at some point, but if I choose it, it
> says it's already registered.
>
> It seems the machine is not listening to my auto-enrolment settings in
> the GPO.
> But Group Policy does appear to be getting applied otherwise.
>
> Don't know if it's relevant, but the original DC was originally a
> win2000, then upgraded to 2003.
> The domain functional level was brought up to 2003.
> It all 'just worked' then.
> This current server is a replacement DC.
> The old one was demoted, and the FSMO roles transferred to this
> machine. No attempt was made to transfer the CA, using this procedure:
> http://support.microsoft.com/default...b;en-us;555012
> That looked like too much work.
> It was simpler to tear it down and re-build it.
>
>
> What further diagnostics can I do to help with this?
>
The situation is fairly complicated, however at root it sounds to me like
the certificate you are creating does not meet minimum server certificate
requirements for EAP-TLS.
My suggestion is that you use the following procedure to configure the
certificate template for autoenrollment to the IAS server. And you can use
the autoenrollment instructions in the whitepaper "Enterprise Deployment of
Secure 802.11 Networks Using Microsoft Windows" at
http://www.microsoft.com/windowsserv...s/default.mspx.
Here is the info/procedure to use to configure the server cert in
Certificate Templates:
Configure server certificates
Use this procedure to configure IAS server certificates for use with PEAP
and EAP.
With PEAP-MS-CHAP v2, PEAP-TLS, and EAP-TLS, servers display a list of all
installed certificates in the computer's certificate store, with the
following exceptions:
-- Certificates that do not contain the Server Authentication purpose in
EKU extensions are not displayed.
-- Certificates that do not contain a Subject name are not displayed.
-- Servers do not display registry-based and smart card-logon certificates.
If you are running an enterprise certification authority (CA) on a computer
running Windows Server 2003, Standard Edition, you can use the Computer
certificate template for server certificates.
If you are running an enterprise certification authority (CA) on a computer
running Windows Server 2003, Enterprise Edition, Windows Server 2003,
Datacenter Edition, the 64-bit version of Windows Server 2003, Enterprise
Edition, or the 64-bit version of Windows Server 2003, Datacenter Edition,
you can use the RAS and IAS Server template for server certificates.
When you configure client computer certificates using this procedure, they
meet the minimum client certificate requirements for PEAP-TLS and EAP-TLS.
In some cases, the values indicated in this procedure are already selected
in the template and you will not have to change settings when configuring
the template.
Administrative credentials
To complete this procedure, you must be a member of the Domain Admins or
Enterprise Admins group.
To configure server certificates using the Windows interface
1. On the computer running Certificate Services, click Start, click Run,
type mmc, and then click OK.
2. On the File menu, click Add/Remove Snap-in, and then click Add.
3. In Available Standalone Snap-ins, double-click Certificate Templates,
click Close, and then click OK.
4. Click Certificate Templates. In the Certificate Templates details
pane, right-click the Computer or RAS and IAS Server certificate template,
and then click Duplicate Template.
5. In Properties of New Template, on the General tab, in Template
Display Name, type a name for the template.
6. Select a Validity period and a Renewal period, or keep the defaults.
7. Click the Subject Name tab, and then verify that Build from this
Active Directory information is selected.
8. In Subject name format, select a value other than None.
9. For server certificates, the Subject Alternative Name
(SubjectAltName) extension in the certificate, if used, must contain the
server's fully qualified domain name (FQDN), which is also called the DNS
name. In Include this information in alternate subject name, select DNS
name.
10. The server certificate must be configured with a required
cryptographic service provider (CSP) value of Microsoft RSA SChannel
Cryptographic Provider. To configure the CSP value, click the Request
Handling tab, and then click CSPs.
11. In CSP Selection, select Requests must use one of the following CSPs.
12. In CSPs, select the Microsoft RSA SChannel Cryptographic Provider
checkbox. Clear all other checkboxes in CSPs.
13. Use Certificate Services Help (and/or the whitepaper mentioned above)
to learn how to configure autoenrollment of the server computer certificate
to domain member server computers.
Also note that EAP-TLS provides mutual authentication, meaning that the
client authenticates the IAS server using the server cert you configure
above.
This means that client computers must have a certificate from your trusted
root CA in the Trusted Root Certification Authorities store -- to get this
cert automatically they must be domain member computers; otherwise you must
manually install this cert on client computers.
When the trusted root CA cert is on the client, the client examines the
server cert that IAS sends and notes that the IAS cert was issued by the CA
that is trusted by the client. This, along with other cert properties that
are correctly configured per the information above, is what allows the
client computer to authenticate the IAS server during mutual
authentication.
--
James McIllece, Microsoft
Please do not send email directly to this alias. This is my online account
name for newsgroup participation only.
This posting is provided "AS IS" with no warranties, and confers no rights.