IIS 7 & IIS 7.5 – How to Create an SSL Certificate Request

IIS 7 & IIS 7.5 – Creating an SSL Certificate Request

Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services

Published 2/21/2012

.

Prelude:

The following is for a request to an online Enterprise CA in a domain scenario.

I put this together after I had to show someone how to create and submit a certificate request in IIS 7. There are mixed information out there on how to do this, but I haven’t found one with simple step by step screenshots in its entirety, so I thought to share this.

This is the same procedure for IIS 7.5.

For IIS 6, the steps are similar, only after you right click on the website properties:

  • Right click the website, choose properties
  • Click on the Directory Security tab
  • Click on Server Certificate button
  • Click Next
  • Then follow Step #3 below, and onwward.

.

I will later add a procedure to create a certificate request file for to send to a Standalone CA, such as a public CA. However, keep in mind, if you’re purchasing a certificate from a public entity, many public CAs provide step by steps with screenshots, and in some cases, such as Digicert (www.digicert.com), that actually help you create the file. I haven’t checked other CAs, but I’m sure they offer similar assistance.

As for an Exchange 2007 or 2010  UC/SAN cert, that is a different topic, and not related to IIS certificate requests. If you want to find out more about Exchange 2007 & 2010 certificates, see the following:

Exchange 2007 & Exchange 2010 UC/SAN Certificate
Published by acefekay on Aug 23, 2009 at 9:44 PM 4420 2
http://msmvps.com/blogs/acefekay/archive/2009/08/23/exchange-2007-uc-san-certificate.aspx

Exchange 2003 works with IIS 6, and the steps involved are not related to this, either.

.

Create and send a Cert Request to an Enterprise CA:

.

1. Open IIS

  • Click on the Servername in the upper left navigation pane.
  • In the results pane (the middle section), right-click on, Server Certificate, and choose Open Feature. Or you can simply double-click on it to open it.

.

.

2. In the Action Pane, choose Create Domain Certificate

.

.

3. Fill in the name of the website that you applications are connecting to it as

.

.

4. Click on Select and browse to the online Active Directory Enterprise CA in your infrastructure.

.

.

5. Click on the Default Website, then click on Edit Bindings

.

.

6. Click on https, then click on Edit

.

.

7. After clicking on Edit, in the Edit Site Binding windows, click on View

.

.

8. Choose the Common Name you created in the SSL cert dropdown box

.

.

9. Optionally you can choose to View the cert properties to ensure you chose the correct one

.

.

10. Open IE, connect to the website, then view the certificate

.

.

11. You can see the cert is the one we selected in the site’s SSL bindings

.

.

I hope you’ve found this helpful.

Comments, suggestions and corrections are welcomed.

Ace Fekay

Create an Active Directory Fine Grained Password and Lockout Policy Passwords Settings Object (FGP & PSO) Step by Step

Create an Active Directory Fine Grained Password and Lockout Policy Passwords Settings Object (FGP & PSO)

Original publish date 2/16/2012
Revised 10/20/2014

Prelude

Ace here, again! I’ve updated this blog to reflect the fact that it’s much easier to create a PSO in Windows 2012, as well as a little background on PSOs.

Scope

Password policies are normally set in the Default Domain Policy. If they are created anywhere else, they won’t work. It’s just a fact of how AD and GPO account settings work. They are a domain specific settings.

Therefore, I thought I would put this blog together to explain them along with a step by step with lots of screenshots, on how to create a Fine Grained Password & Lockout Policy PSO (Password Settings Object) that you can apply to a group of users that will override the domain level Password and Lockout Settings.

And this is for Windows 2008 R2, which is a bit more tedious to create. If you are searching for how to create a PSO in Windows 2012 or Windows 2012 R2, the following link will help:

How to use Fine-Grained Passwords in Windows Server 2012
http://blogs.technet.com/b/uktechnet/archive/2012/08/28/guest-post-how-to-use-fine-grained-passwords-in-windows-server-2012.aspx

*

PSO and FGPP Guidelines

You can create one or more PSOs in your domain. Each PSO contains a complete set of password and lockout policy settings. A PSO is applied by linking the PSO to one or more global security groups or users. Actually, by linking a PSO to a user or a re modifying an attribute called msDSPSOApplied, which is empty by default. This approach now treats password and account lockout settings not as domain-wide requirements, but as attributes to a specific user or a group. For example, to configure a strict password policy for administrative accounts, create a global security group, add the service user accounts as members, and link a PSO to the group. Applying fine-grained password policies to a group in this manner is more manageable than applying the policies to each individual user account. If you create a new service account, you simply add it to the group, and the account becomes managed by the PSO.

Precedence:

A PSO can be linked to more than one group or user, an individual group or user can have more than one PSO linked to it, and a user can belong to multiple groups. So, which fine-grained password and lockout policy settings apply to a user? One and only one PSO determines the password and lockout settings for a s precedence.
The precedence value is any number greater than 0, where the number 1 indicates the highest precedence. If multiple PSOs apply to a user, the PSO with the highest precedence takes effect. The rules that determine precedence are as follows:

• If multiple PSOs apply to groups to which the user belongs, the PSO with the highest precedence wins.
• If one or more PSOs are linked directly to the user, PSOs linked to groups are ignored, regardless of
their precedence. The user-linked PSO with the highest precedence wins.
• If one or more PSOs have the same precedence value, Active Directory must choose. It picks the PSO with the lowest globally unique identifier (GUID). GUIDs are like serial numbers for Active Directory objects—no two objects have the same GUID. GUIDs have no particular meaning—they are just identifiers—so picking the PSO with the lowest GUID is, in effect, an arbitrary decision. You should configure PSOs with unique, specific precedence values so that you avoid this scenario.

These rules determine the resultant PSO. Active Directory exposes the resultant PSO in a user object attribute, msDS-ResultantPSO, so you can readily identify the PSO that will affect a user. PSOs contain all password and lockout settings, so there is no inheritance or merging of settings. The resultant PSO is the authoritative PSO.

To view the msDS-ResultantPSO attribute of a user:

1. Ensure that Advanced Features is enabled on the View menu.
2. Open the properties of the user account
3. Click the Attribute Editor tab.
4. Click Filter and ensure that Constructed is selected.
5. Locate the msDS-ResultantPSO attribute.

PSOs, OUs, and Shadow Groups:

PSOs can be linked to global security groups or users. PSOs cannot be linked to organizational units (OUs). If you want to apply password and lockout policies to users in an OU, you must create a global its membership shadows, or mimics, the membership of an OU.

Note: There is no graphical tool in Windows Server 2008 to create shadow groups.
However, you can create and manage them by using a very simple script that will run
periodically. This script should enumerate user objects in the desired OU and put them in a group.

*

Creating a PSO Step by Step

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

=================================================================

Summary

I hope this helps in your endeavor.

Ace Fekay
MVP, MCT, MCSE 2012, MCITP EA & MCTS Windows 2008/R2, Exchange 2013, 2010 EA & 2007, MCSE & MCSA 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP – Directory Services

clip_image002 clip_image004 clip_image006 clip_image008 clip_image010 clip_image012 clip_image014

 

Complete List of Technical Blogs: http://www.delawarecountycomputerconsulting.com/technicalblogs.php

This posting is provided AS-IS with no warranties or guarantees and confers no rights.

Active Directory Server 2008 R2 – You do not have permission to modify the group %$# (Unknown Japanese or Chinese characters)

Active Directory Server 2008 R2 – You do not have permission to modify the group

Ace Fekay, MCT, MVP, MCITP EA, Exchange 2010 Enterprise Administrator, MCTS Windows 2008, Exchange 2010 & Exchange 2007, MCSE 2003/2000, MCSA Messaging 2003
Microsoft Certified Trainer
Microsoft MVP: Directory Services

Compliled 2/7/2012

 

Background:

  • This was created to test out an issue not allowing to modify a group’s membership by a non-full control delegated account on an OU in response to a post in the following TechNet posting:

Active Directory Server 2008R2 – You do not have permission to modify the group $%#     (Posted 2/6/2012)
http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/dcc48a8d-da01-4477-98a4-a10a8eb1f7ba/ 

  • This was also referenced and documented as a bug by Chris Beams in his blog in the following link:

You do not have permission to modify the group
http://chrisbeams.wordpress.com/2010/05/08/you-do-not-have-permission-to-modify-the-group/

With the following error message that appears with unknown Asian characters:

  • Operating System: Windows Server 2008 R2 Enterprise RTM (not SP1)
  • Performed on a domain controller with the DC’s Rights modified to allow Interactive Logon and Logon Locally for the Local Domain Users group using the rights.exe utility.
  • Modified and customized the Delegwiz.inf template to add Template30 “Modify group membership” based on

Appendix O: Active Directory Delegation Wizard File
http://technet.microsoft.com/en-us/library/cc772784(WS.10).aspx

  • I created a group called Help Desk
  • I created a Domain User called “Ace”
  • Added “Ace” to the Help Desk group
  • Created a user called “Shadow”
  • Logged on as Ace
  • Attempted to add Shadow to the Help Desk group
  • Attempted to add Shadow using ADUC to the Help Desk group by using Shadow’s Member Of tab
  • Attempted to add Shadow using ADAC to the Help Desk group – Unsuccessful – the Add buttons were grayed out

Summary:

  1. The error showed up when I was in the user’s properties, Member tab. I didn’t allow me to add the group to the user. 3
  2. I also wasn’t able to add the user to the group using ADAC.
  3. However, through the group properties, Member tab, I was able to add the user.
  4. I didn not try using ADAC by choosing the user’s properties, but I have a feeling it would have worked.

My conclusion as was noted by Chris Beams (link above), is it appears to be a bug, unless someone else indicates otherwise.

 

.

.

Screenshots Below:

1. I first customized the delegwiz.inf file by just adding Template30. I didn’t feel adding the rest of them was required.
If you can’t see the right bottom of this image to see how I added it in the INF file, here’s the full image:
https://public.blu.livefilestore.com/y1p1DHykm_FT3im726XcmFDKE9ZMTgfZ6I48owb-4hOF4Jj-aZjj9oKr1C3l7OG1AUCsrLBIWFcCOct-eu-ficDXw/AD-%20Delegate%20OU%20-%201%20-%20Modified%20Delegatewiz.inf%20to%20add%20template30.jpg?psid=1

.

.

2. Invoked the OU Delegation Wizard

.

.

3. Chose to Delegate the Help Desk group.

.

.

4. Clicked on “Modify Membership of a Group”

.

.

5. Clicked on “Modify Group Membership” (this was the added permission from Template30, as noted in my customized addition)

.

.

6. Added Ace to the Help Desk group.

.

.

7. While still logged on as Administrator, I chose to Switch User to logon as the delegated user, Ace, which is in the Help Desk group.

.

.

8. Chose “Other User.”

.

.

9. In Shadow’s properties:

  • Right clicked on Shadow
  • Member Of tab
  • Clicked on Add
  • Searched and found the Help Desk group

.

.

10. Before I clicked on OK or Apply, just to point out you can see Shadow is now in the list.

.

.

11. After I clicked on Apply, you can see the error message appear with the unknown Asian characters.

.

.

12. So I decided now to try the Active Directory Administrative Center (ADAC).

.

.

13. The familiar ADAC splash screen…

.

.

14. Chose the Help Desk group.

.

.

15. Clicked on Properties of the Help Desk group. But you can see the Add buttons are grayed out. <sigh>

.

.

16. While still logged on as user Ace, I decided to try using ADUC. I right clicked on Test Group, Properties.

.

.

17. Clicked on Members tab, Searched and found Shadow., then clicked on Add.

.

.

18. Before I clicked on Add or Apply, I just wanted to point out that you can see Shadow is in the Members list.

.

.

19. After clicking on Apply, you can see it accepted the command. Shadow was successfully added.

Errors, suggestions, critique, etc, are all welcomed!

Ace Fekay