#SecureSenses --verbose

This solution is now officially distributed by Microsoft! "Microsoft is offering the Local Administrator Password Solution (LAPS) that provides a solution to the issue of using a common local account with an identical password on every computer in a domain. LAPS resolves this issue by setting a different, random password for the common local administrator account on every computer in the domain. Domain administrators using the solution can determine which users, such as helpdesk administrators, are authorized to read passwords." https://www.microsoft.com/en-us/download/details.aspx?id=46899 https://technet.microsoft.com/en-us/library/security/3062591.aspx

In this post I outline a step by step guide on implementing the solution. This post builds on the previous one. This is mostly a condensed version of the author’s documentation with addition of some items that either I found unclear or were not covered by the author.  In any case you should read the full documentation found here: http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789/file/96116/1/Documentation.zip WARNING: The solution requires schema extension and this should never be taken lightly so do test properly and proceed at your own risk.  The steps described in this section can be carried out on a Domain Controller or a management workstation.  1. Install the CSE including the “Management Tools” This installs:  AdmPwd.ps PowerShell module  GPO templates (AdmPwd.admx and .adml)  Note: I tested this on a domain with a local GPO store. If you are using a Central Store you should check if the templates have been copied.  The fol

Jiri Formacek, a Microsoft Services consultant (based on his LinkedIn profile), has published an excellent local admin password management solution.  The solution uses Group Policy Client Side Extension (CSE) to set random and unique per computer local administrator password that is changed at a user controlled interval (30 days by default). The password is then stored in a confidential Active Directory (AD) attribute. Permission to retrieve the password is controlled using a security group. The solution is described in the documentation so I won’t be repeating what’s there. I’ll go over the main points and some stuff that’s not covered in the official documentation.  I recommend reading the documentation. The solution can be downloaded here: http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789 The documentation can be found here: http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789/file/96116/1/Documentation.zip I

Local administrator password has always been a cause of a headache for security professionals. There hasn’t been a good and free way to manage the password on a large scale and most organizations ended up using the same password on all desktops or even servers. This introduces a number of vulnerabilities, such as: All IT Staff know the password The password is never changed The password inevitably becomes known to the users and various 3rd parties Machines are exposed to pass-the-hash attacks  If an attacker, a malware or an evil insider gains access to a single machine currently logged on under the local admin account they will be able to access all machines by executing a script or using built-in management tools. Moreover, compromise of a single machine will allow an attacker to grab a password hash and use it to access other computers. The local administrator password can be managed using Group Policy Preferences as detailed in the following article:  https://soc

Windows OCSP client requires that the OCSP responder URL is populated in the AIA extension. If it is not included, Windows will not form the OCSP request properly and the validation will fail with Certutil status of "Unsuccessful". The same certificate was successfully validated by a Cisco ASA OCSP client.  According to the RFC2560 Apendix A.1.1: {url} may be derived from the value of AuthorityInfoAccess or other local configuration of the OCSP client. This does not seem to be the case in Microsoft's implementation.  OCSP responder address is specified in the Authority Information Access (AIA) extension.  In Windows CA, this is configured in the properties of the CA on the"Extensions" tab.  Once configured all newly issued certificates will include the OCSP responder address. Without the OCSP extension validation using certutil fails. According to RFC2560, an OCSP request must specify hashing algorithm, issuer name hash, issuer

By default, both downloaded CRLs and OCSP responses are cached by a Windows client. If a time-valid version of the CRL or OCSP response exists in the cache, the client will use the cached version rather than downloading an updated CRL or submitting a new OCSP request.  Caching related configuration is defined in the following registry hive: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\ CertDllCreateCertificateChainEngine\Config A binary value of:  ChainCacheResyncFiletime  defines when cache will be cleared.  Force the cache to be cleared: c:\> certutil –setreg chain\ChainCacheResyncFiletime @now Force the cache to clear in 1 hour: c:\> certutil –setreg chain\ChainCacheResyncFiletime @now+0:1 View current cache life time config: c:\>  certutil –getreg chain\ChainCacheResyncFiletime

1. CA cert request: Enrolling device requests and installs CA cert. SCEP Opertion: GetCACert HTTP Header: GET /CertSrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert&message=SCEPLab HTTP/1.0 Host: 10.0.0.6 2. SCEP server returns the CA cert: In the case of GET operation with a type of GetCACert, the MIME content type returned will  depend on whether or not an RA is in use. If there is no RA, only the CA certificate is  sent back in the response, and the response has the content type tagged as application/x-x509-ca-cert. If there is an RA, as it is the case in this lab, the RA certificates are sent back together with the CA certificates.  The content type is application/x-x509-ca-ra-cert. HTTP Header: HTTP/1.1 200 OK Content-Length: 4170 Content-Type: application/x-x509-ca-ra-cert Server: Microsoft-IIS/8.0 Date: Mon, 29 Apr 2013 09:15:51 GMT Connection: close 3. Device requests an identity certificate: SCEP Operation: PKIOperation HTTP H

1. Install CA cert ciscoasa(config)# crypto ca trustpoint CA ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# enrollment url http://10.0.0.6/certsrv/mscep/mscep.dll ciscoasa(config)# crypto ca authenticate CA  Debug output : CRYPTO_PKI: HTTP response header: HTTP/1.1 200 OK Content-Length: 4170 Content-Type: application/x-x509-ca-ra-cert Server: Microsoft-IIS/8.0 Date: Mon, 29 Apr 2013 11:13:14 GMT Connection: close Content-Type indicates we have received CA and RA certificates. CRYPTO_PKI:crypto_process_ca_ra_cert(trustpoint=CA) INFO: Certificate has the following attributes: Fingerprint:     537adc87 22cc6e2b 07fdf2e0 18d8ba8b The PKCS #7 message contains 4 certificates. CRYPTO_PKI:crypto_pkcs7_extract_ca_cert found cert CRYPTO_PKI: transaction GetCACert completed CRYPTO_PKI: CA certificate received. CRYPTO_PKI: crypto_pki_authenticate_tp_cert() CRYPTO_PKI: trustpoint CA authentication status = 0 Trustpoint 'CA&

As opposed to Windows, Linux doesn't have crypto APIs that would be usable by user-mode applications.  Linux does have Kernel level CryptoAPI (crypto.h) which is accessible to kernel mode processes.  As such applications store certificates in application specific locations. That way we end up with multiple  copies of the same certificate. One way to workaroud is to designate a directory for certificate storage  and create symbolic links in required directories.  The Linux Kernel Cryptographic API overview: https://thesweeheng.files.wordpress.com/2007/11/6451.pdf Generate CSR using a new key pair: openssl req -nodes -newkey rsa:1024 -keyout serverName.key -out serverName.csr Generate CSR using an existing key pair: openssl req -new -key serverName.key -out serverName.csr Once the request is signed, certs and keypair must be copied to relevant location. Most Linux applications  require Base64 encoded certificate with .PEM extension. This however may vary. Apache for ex

Online Certificate Status Protocol (OCSP) is an IETF standard defined in RFC 2560  ( http://www.ietf.org/rfc/rfc2560.txt ). OCSP is used for real-time certificate status checking. OCSP uses HTTP as its transport mechanism. Transaction consists of an HTTP query using an HTTP POST verb and an HTTP 200 response.  1. OCSP request (MIME type: ocsp-request): HTTP header: POST /ocsp HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: application/ocsp-request Accept: */* User-Agent: Microsoft-CryptoAPI/6.2 Content-Length: 86 Host: srv3.kp.local The request contains hash of the issuer's name and public key along with the serial number of the certificate to be validated: 2. OCSP response (MIME type: ocsp-response):  HTTP header: HTTP/1.1 200 OK Cache-Control: max-age=580 Content-Length: 1256 Content-Type: application/ocsp-response Expires: Mon, 22 Apr 2013 10:34:16 GMT Last-Modified : Mon, 22 Apr 2013

One of the ways a CRL can be retrieved is HTTP. Whole transaction consists of an HTTP GET and an OK 200 response packets. The response is a  PKIX-CRL MIME type encoded CRL. PKIX-CRL is an IETF standard defined in RFC 2585 -  http://www.ietf.org/rfc/rfc2585.txt 1. CRL requester generates an HTTP query using an HTTP GET verb HTTP header: GET /pki/IssuingCA-DC1.crl HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Accept: */* User-Agent: Microsoft-CryptoAPI/6.2 Host: dc1.kp.local 2. Server responds with CRL encoded in PKIX-CRL MIME type HTTP header: HTTP/1.1 200 OK Content-Type: application/pkix-crl Last-Modified: Mon, 22 Apr 2013 08:29:51 GMT Accept-Ranges: bytes ETag: "d06e258f333fce1:0" Server: Microsoft-IIS/8.0 X-Powered-By: ASP.NET Date: Sun, 21 Apr 2013 08:46:23 GMT Content-Length: 820 WireShark decodes the PKIX-CRL. We can see all CRL extensions directly in the packet.

ASA supports status verification using CRLs and OCSP. CRL can be retrieved using HTTP, LDAP or SCEP. Revocation checking using CRL: Over HTTP: ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-crl)# protocol http By default ASA will use address listed in CDP extension of the certificate that is being validated.  To override default behaviour we need to add the following in the CRL configuration context. ciscoasa(config-ca-crl)# policy static ciscoasa(config-ca-crl)# url 1 http://cdpurl.kp.local/crl.crl Over LDAP: Certificate I'm using for this lab, doesn't have LDAP address in its CDP extension. Therefore I'm using "policy static"  to specify LDAP URL where CRL can be retrieved.  ciscoasa(config)# crypto ca trustpoint ASDM_TrustPoint2 ciscoasa(config-ca-trustpoint)# revocation-check crl ciscoasa(config-ca-trustpoint)# crl configure ciscoasa

Publish CRL to LDAP store: C:\> certutil -dspublish .\IssuingCA-DC1.crl serverName Validate certificate's Authority Information Access (AIA), Certificate Revocation List (CRL), Online Certificate Status Protocol (OCSP) status : C:\>certutil -URL certname.cer This command launches below UI that can be used to check the following: Note: the certificate in question is revoked Authority Information Access (AIA) - this extension specify location where CA certificates are located ( used for building certification path): CRL accessibility based on CRL Distribution Point (CDP) extension: Revocation status using OCSP: OCSP URL is specified in AIA extension: Download CRL (creates file "Blob0_1_0.crl" in working directory): C:\> certutil-split  -URL http://dc1.kp.local/pki/IssuingCA-DC1.crl View CRL publication related registry entries: C:\> certutil -getreg ca\CRLPublicationURLs Verify re

Privacy Enhanced Mail (PEM) format .cer / .pem      - Base-64 encoded ASCII files  - can be open  in a text editor - Can contain certificates and private keys Distinguished Encoding Rules (DER) format .cer  / .crt / .der - Binary encoded  - Hash of the file matches certificate's thumbprint - Susceptible to corruption due to binary format              (single bit change will invalidate cert as the hash won't match) Public Key Cryptography Standards (PKCS) Cryptographic Message Syntax Standard   - PKCS#7 .p7b / .p7c  - Binary encoded format - Can include whole certification path - Cannot contain private keys Personal Information Exchange - PKCS#12 .pfx / .p12 - Passphrase protected - Can contain private keys - Can include whole certification path References: https://www.sslshopper.com/ssl-converter.html http://technet.microsoft.com/en-us/library/cc738545(v=ws.10).aspx This is very low level Windows API stuff: http