##language:en ## 20160519 AK ---- [[DomainController/CZ|česky]] | '''english''' ---- <> = Task force looking into Domain Controller requirements = !StartCom´s solution: [[http://cert.startcom.org/?lang=en&app=138]] Guide on how to do it: [[http://www.openca.info/docs/guide/openca-guide.pdf|OpenCA Guide, Chapter 3]] This list was generated using the following MS articles * http://support.microsoft.com/default.aspx?scid=kb;en-us;281245 * http://support.microsoft.com/kb/291010/EN-US/ See also MS article "How to enable LDAP over SSL with a third-party certification authority" * http://support.microsoft.com/default.aspx?scid=kb;en-us;321051 == What good is a domain controller cert, and what is it for? == In the world of Microsoft networks a domain controller is the machine in charge, it holds the user information, usernames, passwords and in the case of Windows 2000 or greater much more. Active Directory being an LDAP database, means that the domain is now converted into your global address book for the domain as well, amongst everything else that is held in this database a user may have a list of valid certificates. If that users certificate has the proper information, then the domain will be able to use it to log you on. Since Windows 2000 and better come with the "Microsoft Certificate Authority", that CA obviously handles the creation of all the certificates required. This is fine, but what if I don't want the added overhead of running my own CA, or I think its a bad idea because it won't be trusted and I don't want the headache of trying to make it trusted, or I am just a smart admin who knows that the more certs my dumb users have the more troubles they are going to have knowing which one to use where. Knowing that the Microsoft CA, issues everything I need the first approach might be to ask for a subordinate CA cert. This is an interesting idea and would require the LEAST amount of work on my side. But this would be a very BAD idea for the parent CA, as this subordinate CA can then issue certs that are trusted even though they aren't controlled by the parent CA. If you want an example of this, look at Comodo/InstantSSL this company is a subordinate CA and they will issue a cert to anyone anywhere with no further verification of who you are other than sending the public key portion to the email address given. So if a Subordinate CA cert is a bad idea how do I make this work another way? This is where a "Domain Controller Certificate" comes in. For some reason, which I will not try to fathom, MS doesn't try to verify a certificates via the CRL, or even caching the CRL, at least not in straight forward way. The "Domain Controller Certificate" allows windows to verify a smartcard logon certificates without hitting the issuing CAs CRL every time. So in short a "Domain Controller Certificate" is a special type of certificate used by microsoft networks for verification of smartcard logons. (I am not going to say this is the only thing its used for, but its the only important thing for this discussion) == What makes up a domain controller certificate == * The certificate must have a CRL distribution-point extension that points to a valid certificate revocation list (CRL). * Optionally, the certificate Subject section should contain the directory path of the server object (the distinguished name), for example: CN=server1.northwindtraders.com OU=Domain Controllers DC=northwwindtraders DC=com * The certificate Key Usage section must contain: Digital Signature, Key Encipherment * Optionally, the certificate Basic Constraints section should contain: [Subject Type=End Entity, Path Length Constraint=None] * The certificate Enhanced Key Usage section must contain: a. Client Authentication (1.3.6.1.5.5.7.3.2) b. Server Authentication (1.3.6.1.5.5.7.3.1) * The certificate Subject Alternative Name section must contain the globally unique identifier (GUID) of the domain controller object in the directory and the Domain Name System (DNS) name, for example: Other Name: 1.3.6.1.4.1.311.25.1 = ac 4b 29 06 aa d6 5d 4f a9 9c 4c bc b0 6a 65 d9 DNS Name=server1.northwindtraders.com * The certificate template must have an extension with the BMP data value "DomainController". NOTE: The dsstore.exe -dcmon command does not recognize the certificate without one of these extensions. * You must use the Schannel cryptographic service provider (CSP) to generate the key. * The domain controller certificate must be installed in the local computer's certificate store. Please see this link for the certutil.exe dump of an example certificate http://support.microsoft.com/kb/291010/EN-US/#XSLTH3124121123120121120120 We would need help about configuring OpenSSL for DC CSR see [[http://www.grhq.net/DC_CSR/|proposal for DC CSR]] send comments to <> This link [[http://www.cs.bham.ac.uk/~smp/projects/peap/]] provides information and a patch to create Microsoft IAS PEAP & LDAPS certificates using OpenSSL 0.9.8a and might be helpful to create a Domain Controller certificate: "Windows requires the PKCS12 file to contain a couple of Microsoft specific /Bag Attributes/. Namely the /Crypto Graphic Service Provider/ (oid=1.3.6.1.4.1.311.17.1) set to 'Microsoft RSA SChannel Cryptographic Provider' and !LocalKeySet (oid=1.3.6.1.4.1.311.17.2) set to an empty string. OpenSSL currently doesn't appear to support !LocalKeySet so it's necessary to patch it yourself." == Smartcard logon certificates == Without smartcards there is very little ( I don't know of any ) real benefit of having a "Domain Controller Certificate". So what is needed for a smartcard logon certificate. The CRL Distribution Point (CDP) location (where CRL is the Certification Revocation List) must be populated, online, and available. For example: 1. [1]CRL Distribution Point . Distribution Point Name: . Full Name: . URL=http://server1.name.com/CertEnroll/caname.crl * Key Usage = Digital Signature * Basic Constraints [Subject Type=End Entity, Path Length Constraint=None] (Optional) * Enhanced Key Usage = 1. Client Authentication (1.3.6.1.5.5.7.3.2)(The client authentication OID) is only required if a certificate is used for SSL authentication.) 1. Smart Card Logon (1.3.6.1.4.1.311.20.2.2) * Subject Alternative Name = Other Name: Principal Name= (UPN). For example: . UPN = user1@name.com . The UPN !OtherName OID is : "1.3.6.1.4.1.311.20.2.3" . The UPN !OtherName value: Must be ASN1-encoded UTF8 string * Subject = Distinguished name of user. This field is a mandatory extension, but the population of this field is optional. The more detailed article by Microsoft see [[https://technet.microsoft.com/cs-cz/library/ff404293%28v=ws.10%29.aspx|here]]. We would need help about configuring OpenSSL for DC smartcard CSR see [[http://www.grhq.net/DC_CSR/|proposal for DC CSR]] send comments to <> -------- http://www.cs.bham.ac.uk/~smp/projects/peap/ Here i found some useful information, and a patch to openssl. "Windows requires the PKCS12 file to contain a couple of Microsoft specific /Bag Attributes/. Namely the /Crypto Graphic Service Provider/ (oid=1.3.6.1.4.1.311.17.1) set to 'Microsoft RSA SChannel Cryptographic Provider' and !LocalKeySet (oid=1.3.6.1.4.1.311.17.2) set to an empty string." ---- . CategorySoftware