Go to >> Part-2: Request the certificate the sign the script by user1
Go to >> Part-3: Configure GPO to allow only signed scripts and add user1’s certificate to trusted publisher group on domain computers
Go to >> Part-4: Run the test scripts
Every drivers and built-in softwares in windows environment are pre-packaged with digital signatures. With an increasing number of malicious attacks on windows, every executable, dll or script file should be signed with certificate in domain environment. Moreover, Active Directory & GPO made life easier because it has a very good integration with ADCS services especially with certificate auto enrollment via group policy. This becomes very useful when you want to limit the execution of scripts on servers in your domain environment, preventing malicious scripts from running and unauthorized changes. Today, I will show you how to sign your powershell scripts from Microsoft CA and use GPO to control the execution of unsigned scripts in domain environment.
Scenario:
Let’s say user1 usually write powershell scripts in Contoso organization. Administrator needs to allow only the execution of scripts written by user1 on certain computers, while other scripts are blocked. Moreover, if one of the user1’s script is modified by a malicious user and run on client computers or servers, how can we stop these things? Let’s see how it works.
My Lab Environment:
Go to >> Part-3: Configure GPO to allow only signed scripts and add user1’s certificate to trusted publisher group on domain computers
Go to >> Part-4: Run the test scripts
Every drivers and built-in softwares in windows environment are pre-packaged with digital signatures. With an increasing number of malicious attacks on windows, every executable, dll or script file should be signed with certificate in domain environment. Moreover, Active Directory & GPO made life easier because it has a very good integration with ADCS services especially with certificate auto enrollment via group policy. This becomes very useful when you want to limit the execution of scripts on servers in your domain environment, preventing malicious scripts from running and unauthorized changes. Today, I will show you how to sign your powershell scripts from Microsoft CA and use GPO to control the execution of unsigned scripts in domain environment.
Scenario:
Let’s say user1 usually write powershell scripts in Contoso organization. Administrator needs to allow only the execution of scripts written by user1 on certain computers, while other scripts are blocked. Moreover, if one of the user1’s script is modified by a malicious user and run on client computers or servers, how can we stop these things? Let’s see how it works.
My Lab Environment:
DC1 – the domain controller and the one where ADCS role is installed
(not recommended to install both roles on single server but for the lab, it’s OK ;)
Node1 – the client computer which user1 will request the
certificate for signing his powershell script.
Node2 – the client computer which user 1 script will be run.
As we have to go through many steps for setup. We will break them up into following 4 parts.
Node2 – the client computer which user 1 script will be run.
As we have to go through many steps for setup. We will break them up into following 4 parts.
- Install ADCS service and configure Code Signing Certificate Template
- Request the certificate to sign the script written by user1
- Configure GPO to allow only signed scripts and add user1’s certificate to trusted publisher group on domain computers
- Run the test scripts. Try to make some bad things ;)
1) Install ADCS service and configure Code Signing Certificate Template
Assuming that your domain controller is already setup and Node1 and Node2 are already joined to domain. I'll install Active Directory Certificate Service Role on DC1 and do some initial configuration.
i) Open Server Manager >> Add Roles and Features >> Active Directory Certificate Services
ii) For code signing only, you can install Certification Authority with no additional roles
iii) Click Next, Next and Install. Check Figure-1
Figure-1 Install ADCS Role
After installing ADCS role, we need to configure for the first Certification Authority setup.
On DC1, click the yellow flag and go through the wizards.
Figure-2: ADCS initial configuration
On the "Select Role Services to configure" page, only "Certification Authority" is selected for code signing purpose.
On next page, we choose enterprise CA. It has a good service integration with AD such as certificate auto-enrollment and in our case, all clients needs to automatically trust the root CA which is automatically taken care by Enterprise CA.
Figure-3: Choose CA Type
Next page is "Root CA" or "Subordinate CA". Since it is the first CA in our environment, we choose root CA.
Also, on the new private key page, we do not have a private key yet. So, go with "Create a new private key".
Then choose the key length and encryption algorithm to your suite. For me, I go with the default one. See figure-4.
Figure-4: Choose Cryptographic Option
After that, you have to define the common name of the CA and the validity period of the root certificate. Choose default.
Figure-5: Common Name of CA
Next page is CA database location and final review. Choose default. And done.
2) Configure Code Signing Certificate from Template
So far, we have done the initial configuration for our CA on DC1 Server. Now, it's time to configure the certificate we want to issue, the code signing certificate from built-in template. On DC1 Server,
i) Start >> Administrative Tools >> Certification Authority and expand our newly setup CA.
ii) Right-click the certificate template >> Manage. See Figure-6.
Figure-6: Manage Certificate Template
Then there you will find many built-in certificate templates which are readily available to us. For our purpose, we choose Code Signing Template. Like Default Domain Policy, I highly suggest you to duplicate the built-in template rather than editing the original one directly. See Figure-7.
Figure-7: Duplicate the template for further customization
Many has been change in certificate services since server 2003. This can be found in compatibility settings. Unless you are using these different features, you can set both server and client version to the highest level.
Figure-8: Certiificate Compatibility Setting
Here now, you have to give user1 permission to enroll certificate himself. Since, he has to request the certificate and sign his powershell scripts, he needs to have read and enroll permission on this certificate.
Figure-9: Set permission for CA enrollment
Give the Name of the template and certificate validity period. I give it Powershell code signing and the default validity period and renewal period.Then, click OK. See figure-10.
Figure-10 Set Name and Validity Period of Certificate
So far now, we have basically configured the code signing cerficate template. You can further configure according to your needs such as key usage, request handling. More about certificate template on TechNet article here.
And we put this template on the list of certificates to be issued.
On the Certification Authority, right-click the "Certificate Templates" >> New >> Certificate Template to Issue. See Figure-11.
Figure-11: Put our template to the issuing list
Now, we have setup CA role, initially configure CA and configure our template for code signing. They are only done on DC1 server where AD CS role is installed (I installed AD DS roles on the same computer also because of lack of resources)
On the Part-2, user1 will request our configured certificate from his Node1 computer and sign his script.
Next Part >> Part-2: Request the certificate to sign the script by user1
Figure-1 Install ADCS Role
After installing ADCS role, we need to configure for the first Certification Authority setup.
On DC1, click the yellow flag and go through the wizards.
Figure-2: ADCS initial configuration
On the "Select Role Services to configure" page, only "Certification Authority" is selected for code signing purpose.
On next page, we choose enterprise CA. It has a good service integration with AD such as certificate auto-enrollment and in our case, all clients needs to automatically trust the root CA which is automatically taken care by Enterprise CA.
Next page is "Root CA" or "Subordinate CA". Since it is the first CA in our environment, we choose root CA.
Also, on the new private key page, we do not have a private key yet. So, go with "Create a new private key".
Then choose the key length and encryption algorithm to your suite. For me, I go with the default one. See figure-4.
After that, you have to define the common name of the CA and the validity period of the root certificate. Choose default.
Next page is CA database location and final review. Choose default. And done.
2) Configure Code Signing Certificate from Template
So far, we have done the initial configuration for our CA on DC1 Server. Now, it's time to configure the certificate we want to issue, the code signing certificate from built-in template. On DC1 Server,
i) Start >> Administrative Tools >> Certification Authority and expand our newly setup CA.
ii) Right-click the certificate template >> Manage. See Figure-6.
Then there you will find many built-in certificate templates which are readily available to us. For our purpose, we choose Code Signing Template. Like Default Domain Policy, I highly suggest you to duplicate the built-in template rather than editing the original one directly. See Figure-7.
Many has been change in certificate services since server 2003. This can be found in compatibility settings. Unless you are using these different features, you can set both server and client version to the highest level.
Here now, you have to give user1 permission to enroll certificate himself. Since, he has to request the certificate and sign his powershell scripts, he needs to have read and enroll permission on this certificate.
Give the Name of the template and certificate validity period. I give it Powershell code signing and the default validity period and renewal period.Then, click OK. See figure-10.
So far now, we have basically configured the code signing cerficate template. You can further configure according to your needs such as key usage, request handling. More about certificate template on TechNet article here.
And we put this template on the list of certificates to be issued.
On the Certification Authority, right-click the "Certificate Templates" >> New >> Certificate Template to Issue. See Figure-11.
Now, we have setup CA role, initially configure CA and configure our template for code signing. They are only done on DC1 server where AD CS role is installed (I installed AD DS roles on the same computer also because of lack of resources)
On the Part-2, user1 will request our configured certificate from his Node1 computer and sign his script.
Next Part >> Part-2: Request the certificate to sign the script by user1
This blog post is really very amazing nicely explained every point. Thanks for this interesting blog.
ReplyDeletePDF Signer
Thanks a lot for sharing such a wonderful post.
ReplyDeleteDigital Signature Integration
Digital Signature with SAP
Thanks for publishing the informative blog. Really a helpful blog.
ReplyDeleteBulk PDF Signer