Category Archives: Security

What does the “This certificate has an invalid digital signature.” message actually mean?

I recently got a new Asus RT-N66U Dark Knight. One of my main reasons for selecting this router was its ability to run the DD-WRT custom firmware. DD-WRT offers a host of cool features, among these is the ability to do web based administration on the router’s WAN interface. Basically you can fire up your favorite browser and log on to the web interface of the router from anywhere on the Internet. Of course you wouldn’t want to do that without encryption so the DD-WRT firmware comes with its own self signed SSL certificate. When trying to use this particular feature was when I started to have problems.

I navigated to my routers WAN address while on the Internet using Internet Explorer. I fully expected IE to throw an error regarding the certificate. The certificate in the router firmware was bound to be a generic certificate not containing either my WAN IP or my FQDN in its subject fields. IE lets you continue if there is a mismatch between what you have typed in your browser’s address field and what is specified in the certificate’s subject field. But instead IE gave me this:

image

As you can see the only option is to close the webpage. IE would not even let me see the certificate and look at the actual certificate error. At this point I switched to Google Chrome to see what it had to offer. This is what it said:

image

Chrome let me continue despite the certificate error and I could access the router’s web pages and also look at the certificate:

image

I exported the certificate and dumped it’s information with certutil.exe:

X509 Certificate:
Version: 1
Serial Number: f1509cfb65bfbb46
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00
Issuer:
E=info@dd-wrt.com
CN=NewMedia-NET GmbH
OU=DD-WRT
O=NewMedia-NET GmbH
L=Dresden
S=Saxon
C=DE
Name Hash(sha1): f03bcb463cb28f2c7a590ff0ea429861f2e974b1
Name Hash(md5): 3a7bd1dbec01065f788593f78810a3b5

NotBefore: 28.04.2013 05:46
NotAfter: 26.04.2023 05:46

Subject:
E=info@dd-wrt.com
CN=NewMedia-NET GmbH
OU=DD-WRT
O=NewMedia-NET GmbH
L=Dresden
S=Saxon
C=DE
Name Hash(sha1): f03bcb463cb28f2c7a590ff0ea429861f2e974b1
Name Hash(md5): 3a7bd1dbec01065f788593f78810a3b5

Public Key Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
Algorithm Parameters:
05 00
Public Key Length: 512 bits
Public Key: UnusedBits = 0
0000  30 48 02 41 00 cf 8b 93  48 0c 3d b1 1e 77 bc 62
0010  0a b5 ac 2b 82 cc 10 1c  f0 57 97 9e 17 bc af 82
0020  41 66 6c e1 c2 6b 26 72  0a ea 88 6a d6 7a 51 32
0030  e9 53 99 e6 1b ce 53 10  59 16 74 89 9c 09 a4 0c
0040  3c 9d 13 80 81 02 03 01  00 01
Certificate Extensions: 0
Signature Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.5 sha1RSA
Algorithm Parameters:
05 00
Signature: UnusedBits=0
0000  e7 73 70 c1 62 c8 74 7d  b8 25 66 e7 c7 99 94 cb
0010  8f db 52 82 66 24 d8 b8  3f 4e 3e 76 e3 2e 75 63
0020  af 3d d4 1c c7 4a 99 9d  c4 07 72 cd d3 19 f2 3c
0030  4d 99 a5 15 87 b8 9e 2f  82 1f 15 5d 93 3a 76 94
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): be a4 73 4e 2a 56 40 36 ff 3f 2c 0d 35 32 c3 10 a7 24 b2 2a
Key Id Hash(sha1): a8 7e 4f 69 e0 8c 94 49 13 1a 81 c3 64 32 25 2f 3a ab 85 85
Key Id Hash(md5): d98943eba0509d9518cb725cfddc2024
Key Id Hash(sha256): a42184530c87d0045e4c1c32fa7c2561de9d5d5de477bdd3731a0d858d877dc0
Cert Hash(md5): db c8 74 6a 22 3e d5 ad cf 3d d5 1a bd e0 e4 dc
Cert Hash(sha1): 60 50 8a 06 eb 3e bb 37 df 52 8a a4 f0 96 21 af 5d f0 cb c4
Cert Hash(sha256): 92048e3aeb6fc644e930b4c9e3a1d447e52c346091b826a220717bc31e309993
Signature Hash: 05c91314bbe66b58e6f870f57733dfdb456eb5e0

I do not trust the issuer of this certificate (NewMedia-NET GmbH), but that is not what the message in the certificate properties mean. Neither was this a problem with validity since the certificate is valid for almost 10 years at the time of this writing. Even adding this certificate to the Trusted Root Certificate store will not resolve this problem. The reason is to be found in the Public Key Length field. In this certificate the public key is only 512 bytes. In August of 2012 Microsoft released an update that will block any certificates with RSA keys less than 1024 bits in length. This was done to make sure that a private key cannot be discovered using brute force methods and thus exposing private information. After the update the CryptoAPI, which builds a certificate trust chain and validates that chain by using time validity, certificate revocation, and certificate policies (such as intended purposes), implements an additional check to make sure that no certificate in the chain has an RSA key length of less than 1024 bits. Any such certificates will not be trusted.

Actually the error displayed by Internet Explorer; “The security certificate presented by this web site is not secure” makes more sense than the messages in the certificate properties (“This certificate has an invalid digital signature”). Because that is actually what is happening; the certificate is not good enough to protect whatever data your are transmitting between the client and the server. So how come, according to the CryptoAPI extension, the digital signature is not valid?

In public key cryptography the private key is generated from the public keys, or rather, the very large prime numbers selected to be the public key. That means that if the public key is weak, i.e. less than 512 bytes, the resulting private key would be as well. Since it is the issuing authority’s private key that is used to sign the issued certificate the signature itself would also be weak. And that is why the CryptoAPI displays the message “This certificate has an invalid digital signature”. What it should have displayed is something along the lines of “this certificates was signed with a weak private key etc.”.

If you are desperate to use certificates with key lengths less than 1024 bits you can override the restrictions imposed by the Microsoft update. How to do that is documented in the KB article accompanying the update. Here is the command I ran to test that I was on the right track and force IE to let me use the certificate:

certutil -setreg chainminRSAPubKeyBitLength 512

After running this IE have me this for the certificate:

image

As you can see the signature error is now gone (overridden) and we are back to a regular “this cert is not trusted” message.

But since I did not want to use any weak certs I removed the override and instead replace the certificate on the router with a proper V3 2048 bits certificate. This is the command to revert to the new behavior of blocking keys with less than 1024 bits:

certutil -delreg chainMinRsaPubKeyBitLength

More information:

Understanding X.509 digital certificate thumbprints

Introduction

I got an interesting question about X.509 certificate thumbprints today from a colleague. Specifically, he wanted to know if you could renew a certificate and keep the thumbprint. The answer is no, unfortunately. So I thought I would explain why you can’t.

Certificate storage

The X.509 standard was first issued in 1988 and is described in several RFCs. It specifies, among other things, public key certificates, what we commonly refer to as X.509 certificates. X.509 certificates, in turn, currently come in three versions, v1, v2 and v3. The v3 certificates are described in RFC 5280. For the remainder of this post the terms certificate, public key certificate and X.509 certificate are used interchangeably.

X.509 certificates, as well as many other things in the X.509 standard, are described using Abstract Syntax Notation One (ASN.1). ASN.1 is a standard used to exchange information between systems independently of the systems’ encoding techniques. ASN.1 have several encoding rules:

  • Basic Encoding Rules (BER)
  • Canonical Encoding Rules (CER)
  • Distinguished Encoding Rules (DER)
  • XML Encoding Rules (XER)
  • Canonical XML Encoding Rules (CXER)
  • Extended XML Encoding Rules (E-XER)
  • Packed Encoding Rules (PER, unaligned: UPER, canonical: CPER)
  • Generic String Encoding Rules (GSER)

The original rules laid out for the ASN.1 standard were Basic Encoding Rules (BER), and CER and DER are more strict variants of BER. Digital certificates are usually stored in the file system as raw binary data, so DER (binary) is the most common. Certificates stored as raw binary usually have a .cer extension, but .der is also in use. Often the binary data is converted to Base64 ASCII files. This is called Privacy Enhanced Email (PEM), and these files commonly have one of these extensions: .pem, .crt, .cer, and .key.

Here is a screenshot of a DER encoded certificate opened in a HEX editor:

image

Here is the same cert encoded as Base64 also opened in a HEX editor:

image

Finally here is the same certificate in ASN.1 human readable form (this isn’t the whole cert):

image

So what does all this mean?

The RFC 5280 X.509 certificate definition

In RFC 5280 the basic syntax of a certificate (using ASN.1) defines three required fields:

Field Definition from RFC 5280
tbsCertificate The sequence TBSCertificate contains information associated with the subject of the certificate and the CA that issued it. Every TBSCertificate contains the names of the subject and issuer, a public key associated with the subject, a validity period, a version number, and a serial number; some MAY contain optional unique identifier fields.
signatureAlgorithm The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign this certificate.
signatureValue The signatureValue field contains a digital signature computed upon the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded tbsCertificate is used as the input to the signature function. This signature value is encoded as a BIT STRING and included in the signature field.

The tbsCertificate field is by far the largest containing also any extensions the certificate may have like key usage, alternate names etc. RFC 5280 lists all the possible extensions. signatureAlgorithm contains only one piece of data; the hashing algorithm used by the signing authority to sign this particular certificate. signatureValue contains the signature itself, calculated with the hashing algorithm from signatureAlgorithm.

The signature

To produce the certificate signature the signing authority takes the tbsCertificate field in ANS.1 DER encoded form (binary data) and applies the hashing algorithm to it. Inside the tbsCertificate field are some important fields. Specifically the subject name (CN), the hashing algorithm the signing authority used to sign the certificate and the subject’s public key. By signing all these fields the signing authority certifies that the subject in question does in fact own the public key in the certificate. It is a requirement that the signature field within the tbsCertificate field match the signatureAlgorithm field in the certificate. The important distinction here is that it is only the signature field inside the tbsCertificate field that is included in the signature, not the signatureAlgorithm field.

The Windows Cryptographic API

When a certain implementation uses the certificate it calculates and resolves a lot of information not included in the certificate itself. These are things like hash values of various fields and OIDs used to describe e.g. signing algorithms. Certificate Revocation checking is also usually performed and chaining and validation. One example of this behavior is the Windows CryptoAPI Cryptographic Shell Handler. This is the component that shows you a picture like the one below when you double click a certificate from Windows Explorer.

image

Legend

image Actual fields in the certificate
image Extensions in the certificate
image Computed fields not actually part of the certificate data

The certutuil.exe command line utility goes into even greater detail if you inspect (dump) a certificate:

X509 Certificate:
Version: 3
Serial Number: 6e9235460edbb5944d59f9f1a8f1cfe6
Signature Algorithm:
Algorithm ObjectId: 1.3.14.3.2.29 sha1RSA (shaRSA)
Algorithm Parameters:
05 00
Issuer:
CN=Morgan Simonsen
Name Hash(sha1): 935093f16909002acd98626df485fa22b41d9dfd
Name Hash(md5): c32bdd1ad8eaf126fd96b2f7f23f2b9f

NotBefore: 16.04.2013 10:57
NotAfter: 01.01.2040 01:59

Subject:
CN=Morgan Simonsen
Name Hash(sha1): 935093f16909002acd98626df485fa22b41d9dfd
Name Hash(md5): c32bdd1ad8eaf126fd96b2f7f23f2b9f

Public Key Algorithm:
Algorithm ObjectId: 1.2.840.113549.1.1.1 RSA (RSA_SIGN)
Algorithm Parameters:
05 00
Public Key Length: 2048 bits
Public Key: UnusedBits = 0
0000  30 82 01 0a 02 82 01 01  00 ac ed c3 1d 11 7f 63
0010  db 25 50 2e 9a c6 c1 f5  b7 23 c8 a0 71 a4 6e d6
0020  c8 29 17 8f 76 b6 8c 88  33 bf c9 0e 3d c8 0d 87
0030  11 60 e4 f0 77 ae e5 b4  47 6f b1 35 98 d3 44 d0
0040  52 c7 60 2e 7f e9 6c 3c  61 c2 36 3d a7 f5 32 88
0050  de 3c c4 79 62 91 b0 4b  24 78 a2 2e 6a 29 a9 ee
0060  0e 7a d8 0d 9e 12 7b b2  53 d1 17 8c 01 dc eb fb
0070  18 4d c0 ae df 61 7e 2b  dd 15 b5 65 b3 bc b9 25
0080  58 c9 ed 9e ef 9f 26 9b  79 c3 8e 13 92 9e 62 f3
0090  fe 8d ab 33 b4 40 a1 7b  0e b1 71 56 b4 9d 7b cb
00a0  61 9d 70 1d 9d b4 49 c9  46 42 fc 64 44 67 eb 8b
00b0  ea 7c 29 31 cb 4c 32 12  91 6c dd 04 59 07 51 6a
00c0  e6 40 fa ea 4e b2 ae 64  21 2e 6b 00 99 f0 7c 26
00d0  6e ad 6c 15 18 36 dc 81  61 e9 ce 28 7f f8 89 82
00e0  ee ed c5 ee 54 ee aa cd  01 72 75 71 59 fd fc cd
00f0  4d 53 3e 22 71 47 7f 24  e5 51 28 36 12 09 6b 0d
0100  af c9 37 9b e0 d1 00 67  11 02 03 01 00 01
Certificate Extensions: 1
2.5.29.1: Flags = 0, Length = 44
Authority Key Identifier
KeyID=b4 44 ec b5 97 5f 54 f8 ee e8 7b d0 1e c9 81 92
Certificate Issuer:
CN=Morgan Simonsen
Certificate SerialNumber=6e 92 35 46 0e db b5 94 4d 59 f9 f1 a8 f1 cf e6

Signature Algorithm:
Algorithm ObjectId: 1.3.14.3.2.29 sha1RSA (shaRSA)
Algorithm Parameters:
05 00
Signature: UnusedBits=0
0000  8b 55 a5 5f f2 b3 2d 19  36 e9 9c cc 92 16 4e 62
0010  18 19 19 3e 7d 76 93 dd  04 9b 5e 0e b7 80 d7 38
0020  9d 1f b9 18 c3 6c 28 be  d6 64 a3 be 04 60 fc 63
0030  6d 26 dc 68 2b 3d c0 88  6d 36 22 a7 e7 c4 15 dc
0040  2b af 18 61 10 bb 3b 32  78 a6 36 08 81 29 b5 6a
0050  3e a2 2d c7 d0 31 69 1f  f3 fc 67 b7 df 2d e0 4e
0060  5d 37 ab a4 d1 56 e2 96  55 d7 21 d2 68 74 dc 5f
0070  b2 e5 12 54 e2 34 ae a0  08 9e 26 2f e2 4e 4e 98
0080  86 f7 6e ac ef e0 43 1e  0b 9d 59 3d a3 3d 55 03
0090  11 7c f1 df 00 1d 47 35  43 32 91 2a dc 4d 4b 9e
00a0  22 bf a1 f5 1e 1d ad d0  ee 73 34 99 43 82 5d 9e
00b0  b6 aa db 93 25 77 42 0a  bd d2 b2 9a e9 0e 31 2d
00c0  63 4c 4a 37 51 b4 b6 81  47 a8 94 fd e7 43 82 f7
00d0  ee 66 f1 d0 00 ff cf 9f  b0 a6 40 08 05 b8 ff 94
00e0  0b cd cf 50 e3 73 6a 03  2f 6f 95 8e 1b 51 e7 a7
00f0  ac ff 39 84 8c bf b8 65  41 c9 82 38 93 7c cb ab
Signature matches Public Key
Root Certificate: Subject matches Issuer
Key Id Hash(rfc-sha1): 91 cb 09 47 49 10 66 f1 fb 5b bc 8b 5e 0b b1 43 2c d8 80 b2
Key Id Hash(sha1): 4a eb 50 03 a3 78 80 bd 20 a0 00 da c6 f9 ef 8d cc 07 98 52
Key Id Hash(md5): 6a993e53bd40f8f69483d6da66f22a8f
Key Id Hash(sha256): 6979da8247c3080de96e861e9f000a22d6120170a3982bea4e9f054598f6453f
Cert Hash(md5): 94 08 89 bf 34 7e 17 2f 46 d6 25 49 f8 80 1f 6b
Cert Hash(sha1): 0b 61 2f 71 4b 8d ef d5 59 2b d4 5d a9 fe 8c c5 bb ba 36 48
Cert Hash(sha256): 52c93aa9bd509f8b375e0ec8340d9219bac4386497b521d8a7b800eda22e850c
Signature Hash: dee3cb948ffb745c3047e4f393bcf9144863b733
CertUtil: -dump command completed successfully.

 

The Thumbprint

As you can see from the output of the Crypto Shell Extension and Certutil.exe the thumbprint is a computed field, i.e. not a part of the certificate data itself. In the GUI these are called Properties. In the shell extension the thumbprint is called thumbprint and in the Certutil output it is called Cert hash. From this we can surmise that the thumbprint is some kind of hash or one way function (OWF), whose friendly name is thumbprint. (The fact that the shell extension actually has a field called Thumbprint algorithm also helps.) Certutil is also kind enough to compute both a SHA1 and an MD5 hash for us, while the GUI will only do SHA1. As far as I can tell Windows always uses SHA1 to calculate the thumbprint hash, regardless of which signature algorithm is used in the certificate itself.

So what is the thumbprint a hash of? Turns out it is actually the whole certificate, i.e. the binary data representing the three required fields (tbsCertificate, signatureAlgorithm and signature). You can verify this by using a tool that can generate hashes directly from the certificate binary DER file in the file system. In the screenshot below I have used the HashCheck Shell Extension. This tool has a nice feature where you can paste a hash you have obtained from somewhere and see if it matches any of the computed hashes for the file. Here I have copied the thumbprint hash value from Certutil and pasted into the tool:

image

Since the thumbprint is a hash of the certificate in binary DER encoding this will not work if your certificate is stored in any other format than DER.

Conclusion

So now we have the answer to why you cannot request a new certificate, or renew an existing one, with the same thumbprint. Changing anything in the certificate data will produce a completely different hash result and thus a completely different thumbprint.

The thumbprints purpose is actually to make it easy to locate a particular certificate in the certificate store of a system. Let’s say you have a webserver that needs a certificate. Instead of specifying a certificate by subject name, validity or anything else you just supply the thumbprint to the webserver.

More information

To write this post I created a self signed certificate with my name as the subject. The command I used was this:

makecert.exe -pe -n “CN=Morgan Simonsen” -ss My -r morgan_simonsen.der

You can download all the various versions of the certificate from this post from the following link if you want to look in more detail and compare with what I have written.

There are four files in the archive:

File Format
morgan_simonsen.der Binary DER format
morgan_simonsen.crt PEM (Base64) format
morgan_simonsen.asn Raw ASN.1 ASCII data
morgan_simonsen.txt Certutil –dump –asn of the DER cert

Links

Decoding some certificate enrollment client events

The Events

Windows clients can request certificates on their own (autoenrollment) or with the help of a user. When enrolling for a certificate you may find this pair of events in your Application log:

Source: Microsoft-Windows-CertificateServicesClient-CertEnroll
Event ID: 64
Level: Information
User: S-1-5-18
User Name: NT AUTHORITYSYSTEM
Computer: <servername>
Description: Certificate enrollment for Local system successfully load policy from policy server

Source: Microsoft-Windows-CertificateServicesClient-CertEnroll
Event ID: 65
Level: Information
User: S-1-5-18
User Name: NT AUTHORITYSYSTEM
Computer: <servername>
Description: Certificate enrollment for Local system is successfully authenticated by policy server {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}

Obviously the local system successfully enrolled for a certificate, but what do these actually tell us?

Decoding

Let’s start with the first event with if 65 (remember, the newest events are at the top of the event log). It tells us that a CA, included in a certificate enrollment policy, identified by GUID, has successfully authenticated the system’s enrollment request. In the Windows help we find this about certificate enrollment policies:

Certificate enrollment policy provides the locations of certification authorities (CAs) and the types of certificates that can be requested. Organizations that are using Active Directory Domain Services (AD DS) can use Group Policy to provide certificate enrollment policy to domain members by using the Group Policy Management Console to configure the certificate enrollment policy settings. The Certificates snap-in can be used to configure certificate enrollment policy settings for individual client computers unless the Group Policy setting is configured to disable user-configured enrollment policy.

Unless you have added some yourself, there is one default certificate enrollment policy, the Active Directory Enrollment Policy.

To display the enrollment policies you can run certutil.exe –Policy. It will give you a list of your enrollment policies:

Name: Active Directory Enrollment Policy
Id: {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}
Url: ldap:
NextUpdate: EMPTY
LastUpdate: EMPTY
Url Flags = 15 (21)
PsfLocationGroupPolicy — 1
PsfAutoEnrollmentEnabled — 10 (16)
0x4 (4)
Authentication = 2
Kerberos — 2
AllowUntrustedCA: 0
Priority: 7ffffffd (2147483645)
CertUtil: -Policy command completed successfully.

If you look back at the events at the beginning of this post you will recognize the GUID in the event with ID 65. The GUID in the event is the Enrollment Policy ID. So that event is saying that the system was successfully authenticated against the Active Directory Enrollment Policy. Here is a screenshot of the policy as well:

image

NOTE: If you want to see the defalt certificate enrollment policy and create new ones you need to use Group Policy. You can also create new certificate enrollment policies using the Certificates MMC. See the links below:

Now, if you want to see which CAs are in that enrollment policy you can run certutil.exe –CA (my output is concatenated):

Name: Active Directory Enrollment Policy
Id: {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}
Url: ldap:
6 CAs:

CA[0]:
CAPropCommonName = <CA Name>
CAPropDNSName = <CA Server FQDN>
CAPropCertificateTypes =
0: EFSRecovery
1: EFS
2: DomainController
3: WebServer
4: Machine
5: User
6: SubCA
7: Administrator

CAPropSecurity = <SDDL>

Without the Certificate Enrollment Policy Web Service role service installed, the only way to get certificate policy information from Active Directory is by using LDAP. This can obviously be a problem so the Certificate Enrollment Policy Web Service role service was created to allow certificate policy information to be retreived over HTTPS also. The Web Service functions as a proxy; accepting client requests for policy over HTTPS and querying Active Directory for certificate policy information over LDAP.

So now we know what the first event (ID 65) means.

The next event is much easier; it just says that the system was able to load the certificate enrollment policy successfully from the CA.

More information:

“A certificate cloud not be found that can be used with this Extensible Authentication Protocol” error in IAS

After issuing a new certificate for a Windows Server 2003 running IAS this error presented itself in the IAS console when trying to configure EAP with the new certificate:

image

“A certificate could not be found that can be used with this Extensibel Authentication Protocol.”

This was accompanied by these two events in the System Log:

image

image

This was the new certificate, based on the default Computer template in Windows:

image

Notice the empty subject field, IAS/NPS does not accept certificates with empty subject names for use with EAP or Smart Cards. The certificate template that had been used for this certificate was a duplicate of the default Computer template. The template looked like this:

image

After creating a new template from the default Computer template, now with Subject name format set to Common name, and issuing a new certificate; IAS worked fine.

So don’t use certificate with blank subjects for your IAS/NPS servers…

PGP

A PGP clone that works on Windows: GPG4Win

Display GPG info: gpg.exe –version

Importing your old PGP keys

  1. Open a DOS Window (run CMD.EXE)
  2. cd to the directory where your PGP keyrings (pubring.pkr & secring.skr) live.
  3. Import your PGP keys to GnuPG:
    gpg –import secring.skr
    gpg –import pubring.pkr
  4. You’ll need to go in and assign “ultimate” trust to each public/Secret keypair – this is analogous to PGP’s implied trust key setting:

What are the security benefits of running a service as the Local System Account as opposed to a user account?

With the release of Windows 2000 products from Microsoft, most prominently Exchange 2000, started running their services under the Local System1 account instead of using a dedicated Active Directory User account, or what is commonly known as a service account2. The reason for this was security. As time passed more and more products adapted this approach and now most products do, at least from Microsoft. A result of this is the widespread use of computer objects in Active Directory to grant permissions. The Local System account act as the host computer account on the network and as such has access to network resources just like any other domain account. On the network, this account appears as DOMAIN<machine name>$. Instead of granting permissions to the service accounts, who were typically Domain Admins, we now grant granular permissions to the computer object where the service is running. When the service on the computer accesses e.g. Active Directory it does so at the host computer account and because that computer now has rights and permissions it can access the necessary data. But why is this configuration more secure? Well, that’s what this post will try to answer.

  • Password changes
    A traditional service account (user account) typically had the User cannot change password and Password never expires settings set. This meant that you set the password of the account when you created it and never changed it afterwards. That is not a good security practice. Computer accounts on the other hand are also members of Active Directory and change their password on a regular basis, completely automatic. By using the computer account for your services you get regular password changes for your services.
  • Granular permissions
    Traditional user service accounts were usually added to the Domain Admins group. This facilitated easy access to all resources and the services always worked. If the service account, which could be used on several and sometimes all, computers on the network was ever compromised it would give an attacker virtually unlimited access to the network. By using Local System the account can only be used on the host computer and typically never have any rights on other systems. Furthermore, using the principle of least privilege, the host computer’s account can be given only the necessary permissions required to run the service.

1 Local System, or NT AUTHORITYSYSTEM which is its actual name, is a predefined local account that can start a service and provide the security context for that service. When you run something, a service, a scheduled task or a process as Local System you are running it as the host computer. This has many benefits. For example the system has access to the entire computer, meaning the local SAM, Session 0, and other protected areas which are not immediately accessible to a user, even an administrator. For an administrator to access these protected areas we have to start a process as Local System, which is something only administrators can do. There are also other accounts which represent the system, namely LocalService and NetworkService. LocalService has reduced privileges similar to an authenticated local user account, and operate on the network using a NULL sessions (anonymous). NetworkService also has reduced privileges similar to an authenticated user account, but accesses network resources using the credentials of the computer account in the same manner as a Local System service does. More information about service accounts etc is available in the Services and Service Accounts Security Planning Guide (http://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/default.mspx).

2 What allowed this was a change in the Local System Account which enabled it to authenticate to network resources just as a regular user account.