Windows Server – Install and Configure NDES

Posted on 21/10/2021 by Migrated

KB ID 0000947

Problem

NDES, is the name for what we used to call MSCEP, which was an ‘add-on’ for the Server 2003 family of servers. In Server 2008 it was renamed to NDES. It is a role service that runs on a Certificate Services Server, and is used to create a registration authority (RA) that can issue certificates from your PKI infrastructure to network devices, i.e. Routers, Firewalls and Switches.

Solution

Installing Network Device Enrollment Service

I’m assuming you already have an Active Directory Certificate Services Server setup, if not you can deploy that and add in NDES at the same time.

1. Either: Launch Server Manager > Manage > Add Roles and Features > Below Active Directory Certificate Services select Network Device Enrollment Service.

2. Or: From within PowerShell run the following command;

[box] Install-WindowsFeature –Name ADCS-Device-Enrollment[/box]

Configuring Network Device Enrollment Service

1. Create a domain user (below I’ve called it SVC_NDES) > Add that user to the IIS_IUSRS group on the CA server.

2. From within Server Manager launch the post deployment configuration wizard.

3. Next.

4. Select Network Device Enrollment Service, (if not already selected).

5. Change the account details, to the service account you created above.

6. Enter the details that will be used to enroll the RA certificate.

7. Accept the defaults > Next.

8. Configure.

9. Close.

10. Launch the Certificate Authority management console > Certificate Templates > Right Click > Manage.

11. Open the properties of the ‘IPSec (Offline request)’ certificate > Security Tab > Make sure the account you created (above) has the ‘Enroll’ permission.

NDES Disable Password Requirement.

I’ve read a few blogs and articles that say;

“There is no way for Cisco devices to supply the required password to enroll with NDES/MSCEP, so you need to disable the requirement for a password.”

This is NOT TRUE, however the whole point of issuing certificates via your PKI infrastructure, is that it can scale dramatically. If you are creating passwords and embedding those passwords in all your enrollments, it can get a little unwieldy. So it may be sensible to remove the password requirement.

1. Windows Key+R > regedit {Enter} > Navigate to;

[box] HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Cryptography > MSCEP > EnforcePassword > EnforcePassword [/box]

To disable change the value to 0 (zero).

Update: 22/10/21: You may also need to recycle the SCEP application pool in IIS (on the Certificate Services Server)

From IIS Manager > CA > Application Pools, SCEP. > From the right hand panel > Advanced Settings. > Set Load User Profile to ‘True‘ > OK.

Again in the right panel > Recycle > From IIS Manager > Sites > Default Web Site. > From the right panel, click Restart.

Below you can see the difference, with the password requirement enforced, and without.

2. Restart the Certificate Services Service;

[box] net stop certsvc net start certsvc [/box]

NDES More Password Options and Renewing Certificates

If you do want the more secure option of using passwords, but don’t want to ad a new password every time you have a new enrollment, you can specify that the password does not expire after the default 60 minutes, in fact it never expires. This is handy if you want to renew certificates without generating new passwords. To do that carry out the following procedure;

1. Windows Key+R > regedit {Enter} > Navigate to;

[box] HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Cryptography > MSCEP > UseSinglePassword > UseSinglePassword[/box]

Set the value to 1 (one).

2. Navigate to;

[box] HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Cryptography > MSCEP[/box]

Create a new 32 bit DWORD value called ‘DisableRenewalSubjectNameMatch’ Set the value to 1 (one).

3. If (as above), you are running NDES under a service account, ensure that account has full control of the MSCEP key. (Again don’t forget to restart the Certificate Server service.)

IIS Query String Problem

You may find that with the default IIS settings you may encounter some problems. This is because (by default) IIS will only accept a Query String that’s less than 2048 characters long. If that happens you may see the following errors;

Request URL Too Long
HTTP Error 414. The request URL is too long.
HTTP Error 404.15 – Not Found
The request filtering module is configured to deny a request where the query string is too long.

In the IIS logs you will see errors like;

2014-05-14 16:12:39 192.168.80.130 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=GetCACert&message=hsca04 80 – 192.168.80.150 Mozilla/4.0+(compatible;+MSIE+5.0;+Cisco+PKI) 200 0 0 218

2014-05-14 16:12:39 192.168.80.130 GET /certsrv/mscep/mscep.dll/pkiclient.exe operation=PKIOperation&message=<base64 encoded certificate request> 80 – 192.168.80.150 – 404 15 0 15

2014-05-14 16:19:21 192.168.80.130 GET /certsrv/mscep/ operation=GetCACert&message=any 80 – 192.168.80.160 – 200 0 0 328

2014-05-14 16:19:21 192.168.80.130 GET /certsrv/mscep/ operation=PKIOperation&message=<base64 encoded certificate request> 80 – 192.168.80.160 – 404 15 0 703

To stop that happening open a command window (Run as Administrator), and execute the following command;

Note: If this ‘wraps’ in your browser, it is one command!

[box]

%systemroot%\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/requestFiltering /requestLimits.maxQueryString:"4096" /commit:apphost

[/box]

Then restart the web services;

[box] iisreset /noforce[/box]

Now you can get your network devices to enroll, in the next couple of days, I will post how to enroll from both a Cisco ASA, and a Cisco Router.

Note: If you devices are going to be checking your PKI’s CRL then you will need to set that up.

Windows Certificate Services – Setting up a CRL

Duo: Migrate from LDAP to LDAPS

Posted on 02/02/2020 by PeteLong

KB ID 0001647

Problem

With the impending ‘turning off’ of cleartext LDAP queries to Windows Server, I wanted to make sure my new Duo deployments were already using LDAPS. I got LDAP deployed very quickly and easily, but making the ‘swap’ to LDAPS proved to be massively problematic.

Normally I find Duo a pleasure to deploy, but their technical documentation just confused me for this and I went running up some blind alleys, and eventually ended up logging a call to Duo to try to get it working. So to save you this pain, read on.

Solution

Firstly your domain controller(s) need to be setup to accept LDAPS queries, SORT THAT OUT FIRST. I’ve covered that in the following post;

Get Ready for LDAPS Channel Binding

In the following section I’ll assume you have LDAP already setup on your Duo ADSync, if this is a new deployment, and you are going straight to LDAPS, then you can ignore this next section.

Duo Existing LDAP AD Sync

It goes without saying, (but I’ll say it anyway,) your ADSync should already be connected, if you’re switching room LDAP!

So your domain controller(s) will be using TCP port 389.

Your transport type will be set to ‘Clear’.

Duo Deploy LDAPS for ADSync

The first thing that held me up was reading the Duo documentation, and wondering what I needed to add to my authproxy.cfg file! The truth is;

YOU DON T NEED TO ADD ANYTHING TO AUTHPROXY.CFG!!

Here’s a copy of mine for reference, you ONLY need the sections highlighted, the additional section on mine was for my Cisco ASA RADIUS client;

Rights and Permissions for Duo Service Account

Note: By default the Duo service on your Duo Auth Proxy server will be running under the LOCAL SYSTEM ACCOUNT. I had problems using this account, so I used the service account specified in the authproxy.cfg file. But there are some rights you need to assign to the account first. On the Auth Proxy server, run secpol.msc > Security Settings > Local Policies > User Rights Assignment > Log on as a service > Add User or Group > Add in your Duo service account.

All domain users should have the following right, but let’s take a ‘belt and braces’ approach! On a domain controller open ‘Active Directory Users and Computers’ > Right click your domain > Properties > Security > Advanced.

Add in the Duo service account, and grant;

List contents
Read all properties
Read properties

Note: They will probably, already be selected.

Finally: Add the Duo service account to the LOCAL ADMINISTRATORS group on the Duo Auth Proxy server, (Server Manager > Tools > Computer Management).

You can now open the services console and change the account the service runs under, to the Duo Service account, (Windows Key + R > services.msc > OK > Locate ‘Duo Authentication Proxy Service’ > Properties > Log On > Change the account to your service account and enter the password.) Then RESTART THE SERVICE.

Change Duo ADSync to LDAPS

To do this you are going to need a copy of your Root CA certificate (in PEM format). If you have Microsoft Certificate services make sure you get a copy of the Root CA cert in Base 64 format, (if you don’t, when you open the Certificate with Notepad, it will link like gobbledegook!)

Open your Cert with a text editor, and it should look a bit like this, copy that, (with no additional spaces on the end!) To the clipboard, you will need to paste it into the Duo Admin Panel in a minute.

In the Duo Amin Portal > Users > Directory Sync > Active Directory > ADSync > Change the port on your Domain controllers to 636 (That’s LDAPS TCP Port 636, so it needs to be open on any firewalls between the Duo Auth Proxy, and the domain controllers!)

Go to Transport Type > Change to LDAPS > Paste in your CA Certs PEM information into the ‘SSL CA Certs’ Section > Save Directory.

Why didn’t you tick ‘SSL Verify Hostname’? Simply because it fails when I do that, I’m assuming the common name on the LDAPS cert on my domain controllers is the hostname of the DC, and not its FQDN, so I needed to leave this unticked.

All being well it should say connected.

Troubleshooting Duo LDAPS

Duo have a tool that will check your domain controller certificates are OK. It’s called acert.exe or you can enable debugging, or use the connectivity tool.

VMware Horizon – Replacing Certificates

Posted on 09/05/2019 by PeteLong

KB ID 0001547

Problem

I deployed Horizon v7 a while ago for a client, they messaged me to say their wildcard cert was about to expire, could I replace it in the Horizon infrastructure.

On logging in, sure enough;

Connection Server Details
Status: The service has a minor issue
SSL Certificate: About to expire {Date} {Time}

This is why I like VMware, it’s picked up the problem, and pointed me in the right direction, (the connection servers).

Solution

Firstly you will notice I’ve got two connection servers, DO ONE AT A TIME, then if something breaks, you can still get into the manager! If you only have one connection server, I’d suggest taking a snapshot of it first!

Import your new certificate onto the connection server. Make sure you select local computer when you import it. Then you will notice that your ‘old’ one has a friendly name of ‘vdm‘. Rename vdm to OLD-vdm, then rename the new one to vdm.

Finally, either restart the VMware Horizon View Connection Server service, or reboot the server.

VMware: ISO Upload or Deploy OVA Fails ‘Undetermined Reason’

Posted on 09/01/2019 by PeteLong

KB ID 0001499

Problem

I see this a lot! Usually I assume I just need to change browser, here the error is in Chrome. You can see this if you attempt to upload an ISO file to a datastore, or attempt to deploy an OVF file.

Error

The operation failed for an undetermined reason. Typically this problem occurs due to certificates that the browser does not trust. If you are using self-signed or custom certificates, open the URL below in a new browser tab and accept the certificate, then retry the operation.

https://{host address}

If this does not resolve the problem, other possible solutions are shown in this KB article:
http://kb.vmware.com/kb/2147256

Solution

The client simply does not trust the certificate VMware is presenting, (it’s a self signed certificate). So we just need to trust the CA that issued it! Open your browser and navigate to the hostname/IP of the vCenter. From there choose “Download trusted root CA certificates“.

Your machine should download the certificates in a Zip file. Open and extract that file. Locate the security certificate and double click it > Install Certificate.

Next > Select “Place certificate in the following store” > Locate the “Trusted Root Certification Authorities” container, and select that > Next > Finish.

When prompted select “Yes” > OK.

Try again.

Cisco WLC: EAP-TLS Secured Wireless with Certificate Services

Posted on 04/04/2018 by PeteLong

KB ID 0001420

Problem

Ah certificates! If I had a pound for every time I’ve heard “I don’t like certificates”, I could retire! The following run through is broken down into the following parts;

Note: If you are scared of certificates, sometimes it’s easier to setup password (PEAP) Authentication, get that working then migrate to EAP-TLS, but I’ll leave that to you.

Setup The Cisco WLC (WLAN)

I’m assuming your WLC is deployed, and working, and all your AP’s are properly configured, we are simply going to add a RADIUS Server and configure a new wireless LAN to use that RADIUS server for authentication.

WLC RADIUS Setup

Log into the WLC web console > Security > AAA > RADIUS > authentication > New.

Specify the IP address of the RADIUS server and a shared secret (you will need to enter this on the Windows RADIUS server, so write it down!) > Apply.

WLC WLAN Setup

WLAN > Create New > Go.

Specify a profile name, and SSID for the new WLAN > Apply

Edit your new WLAN > Select enabled. If your WLC has many VLANs/Interfaces select the one you want your wireless clients to egress on. Note: you can also turn off SSID broadcast if you wish, remember your GPO will need an additional setting if you do this.

Security > Layer 2 >Set the following;

Layer 2 Security: WPA+WPA2
WPA +WPA2 Parameters: WPA2 Policy-AES
Authentication Key Management: 802.1x

Security Tab > AAA Servers.

Authentication Servers: Enabled
Server1: {Your RADIUS Server}
EAP Parameters: Enable

Note: You may wish to scroll down, and remove Local and LDAP authentication methods, but you dont have to.

Click APPLY.

Save Configuration > OK > OK.

SETUP Windows NAP (RADIUS)

Network Access Protection is a server ‘Role‘, Launch Server Manager > Local Server > Manage >Add Roles and Features > If you get an initial welcome page, tick the box to ‘skip’ > Next > Accept the ‘Role based or feature based installation’ > Next > Next > Add ‘Network Policy and Access Server’ > Next > Add Features > Next > Next > Network Policy Server > Next Install.

Go and have a coffee, when complete open administrative tools ‘Network Policy Server.’ Right click NPS > Register server in Active Directory.

Radius Clients > New > Enter a friendly name >Enter the IP address of the WLC > Enter, and confirm the shared secret you used above > OK.

Note: This may be a different IP to the management IP of the WLC, ensure you enter the correct IP that the AAA requests will be coming from.

Connection Request Policies > New > Give it a sensible name > Next.

Add > NAS Port Type > Wireless- IEEE 802.11 > Wireless Other > OK > OK.

Note: You don’t actually need ‘Wireless other’, I usually add it for Meraki and it’s force of habit.

Next > Next > Next.

Next > Finish.

Network Polices> New > Give it a sensible name > Next

Add > NAS Port Type > Wireless- IEEE 802.11 > Wireless Other > OK > OK.

Note: You don’t actually need ‘Wireless other’, I usually add it for Meraki and it’s force of habit.

Next > Access granted > Next.

Add > Microsoft Smart Card or Other certificate > OK

Note: If you wanted to use PEAP then then you would add this here instead!

Untick all the bottom options, (unless you are using PEAP, which would need MS-CHAP-v2) > Next.

Edit > Ensure the certificate information for the NAP server is correct > OK > Next.

Next > Nap Enforcement > Untick ‘Enable auto remediation…’ > Next.

Finish.

Setup Certificate Auto Enrolment

Again I’m assuming you have a domain PKI/Certificate Services deployment already, if not, then follow the instructions in the post below;

Microsoft PKI Planning and Deploying Certificate Services

So rather than reinvent the wheel, I’ve already covered computer certificate auto enrolment, see the following article, then come back here when you are finished.

Deploying Certificates via ‘Auto Enrolment’

At this point: You might want to connect to the WLAN manually to make sure everything is OK before deploying the settings via GPO!

Deploy Wireless Settings via Group Policy

Remember this is a Computer Policy, so it needs to link to an OU that has computer (not user) in it, create and link a new GPO > then give it a sensible name.

Edit the GPO.

Navigate to: Computer Configuration > Policies > Window Settings > Security Settings > Wireless Network (IEEE 802.11) Policies > Create A New Wireless Network Policy for Windows Vista and Later Releases.

Give it a name > Add > Infrastructure > Supply the Profile name and SSID, (I keep them the same to avoid confusion).

Note: As mentioned above, if you are not Broadcasting the SSID, then also tick the bottom option also.

Security Tab: Authentication = WPA2 Enterprise > Encryption = AES > Change Authentication Method to Microsoft Smart Card or other certificate > Properties > In here you can choose to verify the NAP server via its certificate, if you do then locate and tick your CA server cert in the list (as shown). Though I do not ‘verify the servers identity…’ So I would untick this option (your choice) > OK > OK > Close the Policy Editor.

Then either wait fo the policy to apply for force it.

Windows – Forcing Domain Group Policy

Troubleshooting RADIUS Authentication

On the NAP server in C:\Windows\System32\Logfiles you can find the RADIUS logs they look like INI{number}

You can also use the Event Log (Security Log) and there’s a dedicated logging section under Windows Logs. In extreme cases install Wireshark on the NAP server and scan for traffic from your WLC

Publishing Remote Desktop Services With Web Application Gateway

Posted on 23/01/2016 by PeteLong

KB ID 0001143

Problem

Getting this article to completion has been a bit of a journey! This is the final post that will stitch together all the others I’ve posted over the last couple of weeks, that will enable you to publish your RemoteApps with ‘Remote Desktop Web Access’, and have that service presented securely from your DMZ. I’ll be using Active Directory Federation Services, (you don’t have to, but it’s more secure than simply using ‘pass-though’ security).

Solution

Prerequisites

Topology: Simply getting your ‘ducks in a row’ will take a lot longer than actually deploying the service. Here is the topology that I’m going to deploy;

Firewall Rules: You will see I’ve labelled all the Certificate/CRL rules as optional, this is because you would only need them if you were using self signed certificates. In this example that’s what I am doing, this means that all my remote clients need the root certificate installing on them, so for production I suggest you purchase a publicly signed wildcard certificate for simplicity.

DNS Requirements: For your internal domain and the DMZ it’s simple enough but your external clients will need to be able to resolve your public URL (and the URL of your CRL is used).

Certificate Services (Optional): If you want to deploy self signed wildcard certificates you will need a PKI environment and a published CRL. See the following article;

Windows Certificate Services – Setting up a CRL

Once setup you will need to generate a self signed wildcard certificate. See the following article;

Certificate Services – Create a ‘Wildcard Certificate’

Active Directory Directory Services: You need to have your ADFS farm deployed and ready to add your relying trust to. See the following article;

Deploy Active Directory Federation Services

Web Application Proxy: The Role needs installing ready to have the publishing rule added for Remote Desktop Web Access. See the following article;

Deploying Windows ‘Web Application Proxy’

MAKE SURE: You have ran Windows updates on the WAP server, there are a number of bugs that have been fixed, ensure you have at least KB2975719, and in addition you need to have KB2983037 Hotfix installed.

Step 1: Add A Relying Trust To Active Directory Federation Services For Web Application Proxy

On your ADFS Server > Administrative Tools > AD FS Management > AD FS > Trust Relationships > Relying Party Trusts > Add Relying Party Trust.

Next.

Enter data about relying party trust manually > Next.

Give the trust a name > Next.

AD FS Profile > Next.

Next.

As an identifier, add in the UEL to access Remote Desktop Web Access > Next.

I do not want to configure multi-factor authentication settings for this relying party trust at this time > Next.

Permit all users to use this relying party > Next.

Next.

Untick “Open Edit Claim Rules dialog for this relying party trust when the wizard closes’ > Close.

You should see your relying part trust listed, take note of its name.

Step 2: Configure Web Application Proxy To Publish Remote Desktop Web Access

On the WAP Server > Administrative Tools > Remote Access Management > Select the Server > Publish.

Next.

Select ‘Active Directory Federation Services (AD FS) > Next.

Note: As mentioned above, you can choose ‘pass-through’, then author authentication is done on the internal RD Web Access server (which is less secure).

Select the relying trust you created above > Next. (If it’s not there check https is open, and you can resolve the AD FS service name) > Next.

Give the publishing rule a name, and enter the URL the service will be published on, (this is usually the same inside and outside but does not have to be) > Select your wildcard certificate > Next.

Publish.

In PowerShell execute the following command;

[box]

Get-WebApplicationProxyApplication -Name “SmoggyNinja Remote Desktop Web Access” | Set-WebApplicationProxyApplication -DisableHttp

[/box]

Then the following command;

[box]

Get-WebApplicationProxyApplication -Name “SmoggyNinja Remote Desktop Web Access” | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$true
[/box]

Note: You only actually need this command if you’re using different URLs but let’s stick with a script that works.

Step 3: Additional Works.

On the Remote Desktop Session Host Server run the following commands;

[box]

Import-Module Remote Desktop

Set-RDSessionCollectionConfiguration -CollectionName SN-RDS-COLLECTION -CustomRdpProperty “pre-authentication server address:s:https://remote.smoggyninja.com`nrequire pre-authentication:i:1″

[/box]

Event ID 12016

Posted on 17/11/2015 by Migrated

KB ID 0000292

Problem

Event ID 12016

There is no valid SMTP Transport Layer Security (TLS) certificate for the FQDN of <domain>. The existing certificate for that FQDN has expired. The continued use of that FQDN will cause mail flow problems. A new certificate that contains the FQDN of <domain> should be installed on this server as soon as possible. You can create a new certificate by using the New-ExchangeCertificate task

Cause: One of the server installed certificates that has the “S” attribute (SMTP) has expired, If its the main certificate for the serve then you will need to replace it. However this is common on server that still have a copy of the certificate they self signed and used when exchange was first installed. So you are not using them anyway.

Solution

I’m assuming that the certificates that have expired are not the ones you are using in anger, lets make sure.

1. To see what certificates are being used for what. Launch “Exchange Management Shell” > Issue the following command;

[box] Get-ExchangeCertificate [/box]

2. Above you can see I’ve got three certificates and they all are being used for SMTP, lets make sure they are all in date.

3. Click Start > mmc {enter} > File > Add/Remove Snap-in > Certificates > Add > Select “Computer account” > Next > Accept the default of “Local computer” > Finish > OK > Expand Certificates > Personal > Certificates.

4. Look down the expiration date section and you can see which ones are out of date, compare this list to original one, and you can see which certificates need removing.

5. You can remove the expired certificated from here by right clicking > Delete.

6. OR, you can delete the certificates from within powershell with the following commandlet;

[box] Remove-ExchangeCertificate {thumbnail of certificate} [/box]

7. Then press Y and {Enter} to confirm.

8. Either when you are finished you should be looking more like this.

Note: Without an SMTP certificate with the FQDN of the server you may see Event ID 12014.

Error:

Microsoft Exchange couldn’t find a certificate that contains the domain name <name> in the personal store on the local computer. Therefore it is unable to offer the STARTTLS SMTP verb for any connector with a FQDN parameter of <name>. Verify the connector configuration and the installed certificates to make sure that there is a certificate with a domain name for every connector FQDN.

You can simply create a self signed certificate with the FQDN of the server and import it, then set it for SMTP (Note: it WONT overwrite the one you are using). Or click here.

Windows Server – Enable LDAPS

Posted on 17/11/2015 by Migrated

KB ID 0000962

Problem

Active Directory is built on LDAP, I’ve known this for a long time, but other than it’s a directory protocol that’s about all I did know. Like any directory, if you want information when you query the directory it returns a result. The problem is that information is sent in ‘cleartext’, which is not ideal. To address that you can secure and encrypt that traffic with SSL.

The reason I’m concerned with LDAPS this week, well I was deploying, an RSA Authentication Manager Appliance and when I tried to add Active Directory as an Identity source, this happened;

RSA Operations Console

Add New Identity Source

There was a problem processing your request.
Test connection failed. One
or more directory connections is incorrect.

Solution

To query a domain controller over LDAPS you need a certificate to secure that communication, techies tend to back away when PKI is mentioned, I’m not sure why, but most people fear what they don’t understand, and encryption is pretty complicated,but just think;

PKI issues certificates to things.
The certificates make stuff work.
They expire and need to be renewed.

With that in mind, there are two ways for us to solve this problem. Option 1: Install an enterprise root CA on one of your domain controllers, (that fixes all these problems in one hit). If you only have one server that’s probably our best option, but in any production network thats not a very elegant solution. So Option 2: Is setup a domain PKI solution and use that.

If you already have a PKI/CA infrastructure great, if not, then simply pick a server and launch Server Manager > Manage > Add Roles and Features > Add in the Active Directory Certificate Services role > Follow the on screen prompts.

Actually setting up PKI is outside the scope of this article, I’m running with the assumption that you have a Root/Enterprise CA setup and ready to go.

1. On your CA Server launch the Certification Authority Management Console > Certificate Templates > Right Click > Manage.

2. Locate the Kerberos Authentication certificate > Make a Duplicate.

3. General Tab > Call it ‘LDAPoverSSL’ > Set its validity period > Decide if you want to publish the cert in AD.

4. Request Handling Tab > Select ‘Allow private key to be exported’ > Apply > OK.

5. Right click Certificate Templates again > Certificate Template to issue.

6. Locate and select the ‘LDAPoverSSL’ certificate > OK.

7. Now logon to a DOMAIN CONTROLLER > Windows Key+R > mmc {Enter} > File > Add/Remove Snap-in > Add in the Certificates Snap-In > Computer account > Finish > OK > Expand Certificates > Personal > Certificates > Right Click > All Tasks > Request New Certificate > Next > Next.

8. Select the LDAPoverSSL Certificate > Enroll > Close the Certificate Snap-in.

9. In my case I need my device to ‘Trust’ the CA, So on the CERTIFICATE SERVER > open a command window and run the following command;

[box]
certutil -ca.cert ca_name.cer
[/box]

10. It will display the certificate PEM on the screen and should complete successfully.

11. You will notice my command was run while I was on the root of the C: Drive, yours will probably be C:Users{your-username} go there and retrieve a copy of the ‘Root Certificate’.

Testing LDAP and LDAPS

12. On another server > Open a command windows and run ldp > Connection > Connect > Type in the FQDN of the DC > Set the port to 636 > Select SSL > OK > It should return some results

Note: If you get an error you may need to reboot the domain controller.

That’s your DC configured (You can repeat the process for further DC’s), but remember Imtrying to connect my RSA Appliance.

Adding Active Directory to RSA Authentication Manager

13. Log onto the Operations Console (https://{fqdn}/oc) Deployment Configuration > Identity Source Certificates > Add New > Add in the Root-Cert you exported above.

14. This time when I add my Active Directory as an Identity Source, it completes without error.

Deploying Certificates via ‘Auto Enrollment’

Posted on 17/11/2015 by Migrated

KB ID 0000919

Problem

SHA CERTIFICATE WARNING: Note This article was written some time ago, ensure your CA environment does NOT use SHA1 for your certificates, if it does, Please visit the following link for migration instructions;

Upgrade Your Microsoft PKI Environment to SHA2 (SHA256)

I need to setup wireless authentication based on computer certificates, I’ve done similar jobs before by manually issuing certificates for Cisco AnyConnect, but this will be for NAP/RADIUS authentication to MSM. I’ll be working with Server 2008 R2 and Windows 7 clients. So task one was getting my head round ‘auto enrollment’. As stated I’m deploying Computer certificates but the process is practically the same for issuing User certificates (I’ll point out the differences where applicable).

Solution

Prerequisites: A Windows domain environment, with working DNS.

Setup a Certification Authority

1. Launch Server Manager (Servermanager.msc) Roles > Add Roles > Active Directory Certificate Services > Next > I’m going to accept all the defaults.

2. The only thing I’m going to change is the lifetime, I usually change that from 5 to 10 years (force of habit, after 5 years it will probably still be my problem, in 10 years it will be replaced, or in a skip!)

Create a Computer Certificate Template and Issue it.

3. Start > Administrative Tools > Certification Authority > Certificate Templates > Manage.

4. Locate and make a copy of the Workstation Authentication template. If you were using User certificates the you would copy the User template.

Note: I got an email a few months ago form someone who had an argument about whether to make copies or edit the originals, and was asking what I thought was best practice. Well I would ALWAYS copy a template and edit that copy. Then if you ‘stuff it up’ you still have the original. It’s always best practice to avoid looking like a cretin!

5. If you still have Server 2003 servers choose the default, if not pick 2008 > OK.

6. General Tab > Give the template a sensible name.

7. Subject Name Tab: Tick User principle name (UPN).

8. Security Tab: Ensure Domain Computers have the rights to Read and Autoenroll > OK > Close the template console.

9. Certificate templates > New > Certificate Template to Issue.

10. Pick the one you just created > OK.

11. Make sure it’s listed > Close the Certificate Authority management console.

Deploy Auto-enrolled Certificates via Group Policy

Note: You could just add this to the to the default domain group policy, and all computers would get a certificate, but for this exercise I’ve created an OU, and I’m going to create a new policy and link it there.

12. Select an OU or container that contains the computer objects you want to send certificates to.

Note: Obviously if you are sending out User certificates then link it to a user OU, (you would be surprised!)

13. Navigate to;

[box]

Computer Certificate Auto-Enrollment

Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment

User Certificate Auto-Enrollment

User Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrolment

[/box]

WARNING: If deploying user certificates read this article.

14. Enable the policy > Select the two options available > Apply > OK > Close the GPO management editor.

Test Windows Certificate Auto-Enrollment

15. Before we do anything else, you can see there are no certificates on the Windows 7 client machine, and there are no certificates ‘issued’ from the server.

Note: To see a computers certificates, you need to be logged in with administrative rights, run mmc and add in the certificates snap-in for ‘local computer’.

16. Now if I move this machine into the OU that I’ve linked the GPO to.

17. And then force that client to refresh its group policies, (or reboot it).

18. Now when you check, you can see it has received a certificate, and the server is now showing one certificate issued.

Now I’ve got to work out NAP and RADIUS and force them to use the certificates, but I’ve got a headache and I need a brew, watch this space….

Exchange / Outlook – Security Alert – “The security certificate was issued by a company you have not chosen to trust”

Posted on 17/11/2015 by Migrated

KB ID 0000454

Problem

Out of the box Exchange 2007 and 2010 comes with a “Self Signed” digital certificate. That’s OK for getting you up and running but your Outlook clients may start to see the error below.

Error:
Security Alert
Information you exchange with this site cannot be viewed or changed by others. However, there is a problem with the sites security certificate.
The security certificate was issued by a company you have chosen not to trust. View the Certificate to determine whether you want to trust the certifying authority.

Solution

You have a number of options to stop this error.

Option 1 (This is WHAT YOU SHOULD DO!)

You should purchase a certificate signed by a trusted certification authority, these used to cost a fortune, but if you shop around you can pick them up very cheaply.

Obtaining, and Installing an Exchange Certificate.

Option 2 (Free, and handy if you don’t have a lot of clients)

It still amazes me that people with pay out for a new server, and Exchange, but then refuse to buy a certificate? But if your reading this then that might well be you. You can choose to trust the certificate that’s being presented to you. You carry out this procedure on each Outlook client. If you have a lot of Outlook clients then skip to options 3 and 4).

1. First, start up Outlook and get the error message on the screen.

2. Select “View Certificate” > Install Certificate > Next.

3.Selct “Place all certificates in the following store” > Browse > Select “Trusted Root Certification Authority > OK.

4. Finish.

5. Select yes to accept the certificate import> Restart Outlook.

Option 3 (Free, and handy if you have a lot of clients)

Install Certificates with Group Policy GPO

Option 4

Install your own certification authority, and sign your own Exchange certificate. Great if you already have a CA, though it’s a mess about just to solve this problem.

Problem

Solution

Installing Network Device Enrollment Service

Configuring Network Device Enrollment Service

NDES Disable Password Requirement.

NDES More Password Options and Renewing Certificates

IIS Query String Problem

Related Articles, References, Credits, or External Links

Problem

Solution

Duo Existing LDAP AD Sync

Duo Deploy LDAPS for ADSync

Rights and Permissions for Duo Service Account

Change Duo ADSync to LDAPS

Troubleshooting Duo LDAPS

Related Articles, References, Credits, or External Links

Problem

Solution

Related Articles, References, Credits, or External Links

Problem

Solution

Related Articles, References, Credits, or External Links

Problem

Setup The Cisco WLC (WLAN)

WLC RADIUS Setup

WLC WLAN Setup

SETUP Windows NAP (RADIUS)

Setup Certificate Auto Enrolment

Deploy Wireless Settings via Group Policy

Troubleshooting RADIUS Authentication

Related Articles, References, Credits, or External Links

Problem

Solution

Step 1: Add A Relying Trust To Active Directory Federation Services For Web Application Proxy

Step 2: Configure Web Application Proxy To Publish Remote Desktop Web Access

Step 3: Additional Works.

Related Articles, References, Credits, or External Links

Problem

Solution

Related Articles, References, Credits, or External Links

Problem

Solution

Testing LDAP and LDAPS

Adding Active Directory to RSA Authentication Manager

Related Articles, References, Credits, or External Links

Problem

Solution

Setup a Certification Authority

Create a Computer Certificate Template and Issue it.

Deploy Auto-enrolled Certificates via Group Policy

Test Windows Certificate Auto-Enrollment

Related Articles, References, Credits, or External Links

Problem

Solution

Related Articles, References, Credits, or External Links