What is the state of your delegation?

Have you a documented and recent report over the permissions in your Active Directory?

Have you granted permissions on the relevant OU's in the past and left it like this ever since??

Maybe it’s time to take a look again to see what’s actually delegated in Active Directory?

Things you probably find when re-visiting the permissions: 

• Permissions given to users or groups that does not exist anymore.
• Permissions set to high up in the OU structure so users have the possibility to create/delete/modify Active Directory objects in the wrong places.
•  The permissions grant the user more than needed e.g.  Helpdesk is supposed to reset passwords on user’s accounts in the defined OU but can create\delete any type of objects.
• Same set of permissions delegated to two groups. Usually only one group is needed for one set of permissions.
• Permissions granted to users or groups that is not needed anymore. This can happen when enabling a project to create objects for a limited period of time or if there were a transition between out-sourcing partners.

What to do?

Every Active Directory should have a documented delegation model that includes the permissions set for the data in Active Directory.
I'm not saying you should type down every single permission on every object, but the permissions that is needed for you organization to be able to perform their given tasks. 

Here's a simple example of how you could document Helpdesk's permissions in AD: 

To verify that the permissions in Active Directory is reflecting the need of you organization you have to go through every OU in your Active Directory where permissions is modified.

It's usually a quite daunting task to click your way through the directory tree to get control over the permissions. For every OU or any object for that matter there are at least 4 clicks to reach the Advanced Security Settings tab, which is often the required view, and if you got a large OU structure that could take a while.

 AD ACL Scanner

To simplify the work of creating and documenting the delegation model in Active Directory I have written a tool in PowerShell with a GUI.

This tool creates reports of the access control list for all of your Active Directory objects. With these reports you can see what/where and when permissions have been set.

To run the script you need at least PowerShell 2.0 and Windows 7/Windows Server 2008, (Windows Server 2003 with Limited functionality).

Enabled unsigned scripting:

Set-ExecutionPolicy Unrestricted

If you are not local admin and cannot set it on your machine you can set it for your profile:

Set-ExecutionPolicy Unrestricted -Scope CurrentUser

You do not need Powershell Module for Active Directory.

To create a report for an OU.

1. Click Connect and the tool will connect to your domain.
2. The Domain Node will be populated in the large tree view box below and you can click your way to the OU.
3. When the OU is selected click Run Scan and you will get a HTML report of the permissions.

This is an example of a report:

By default you will only get the selected OU, but if you like to list all sub OU's you can clear the One Level check box. Be aware that it can take a long time to though a large OU structure.

To get the date when the permissions where modified check the Replication Metadata check box. This will add a column to the report with the latest change of the permissions on each object in the report.

This is an example of a report with the date when the access control list was modified.

To browse all objects, click All Objects in the Browse Options box. This is necessary when you would like to get the permissions on another object like a user for example. Then you also have to select All Objects in the Report Objects box too.

If you like to create a report of the whole domain I strongly suggest you select CSV file in the Output Options since it will take a long time to go through all OUs and create a HTML table for it. If you select CSV file it will be much faster and you can convert it to a HTML report afterwards in the Additional Options. You can even use it for comparison.

The Power of AD ACL Scanner

- Comparing

The cool thing with AD ACL Scanner is that you can compare the current state with a previous result. If you select to create a CSV file of the report you can use that to compare the current state with this file and you will get a report of what is missing or what is added.

 This is an example of a comparison report:

 - Filtering

Another nice feature is the filtering feature.

• You can filter on Allow or Deny permissions.
• You can filter on object types, like user or computer.
• You can filter on Trustee, this is a free text field where you can type any kind of name you are looking for. For example: QLIP\JaneGonzalez.

Here's an example of a report with filtering:

Go ahead and download AD ACL Scanner script from Codeplex:

https://adaclscan.codeplex.com/

Go ahead and explore permissions in AD!

I encourage you to get to know your permissions in AD and starts to document it.

Step-by-step walkthrough: installing an Operations Manager 2012 Gateway Server

To make this document, I installed 3 test servers; the evaluation image of Windows Server 2008 R2 can be downloaded from the Microsoft site here: http://technet.microsoft.com/en-us/evalcenter/dd459137.aspx

This installation was done on a generation 1 Core i7 portable with 1 SSD drive and 8GB of memory. The ISO image and the 3 Hyper-V VMs are on that 1 SSD drive. All at the same time installing, while opening Microsoft OneNote and Microsoft Word and creating this document – it’s not slow at all!

Windows 8 is great!!!

And so is OneNote – Windows+S gives you a really nice integrated screenshotting tool!

The setup will be as follows:

- OM12DC: Active Directory, including AD CS (Certificate Services) to generate the certificates for the gateway server. AD CS will be installed as an online enterprise root CA.

- OM12MS: management server, including Operations Manager Reporting, the Operational database and the Data Warehouse database

- OM12GW: a separate server in a workgroup. This one is the reason we need to have AD CS.

This document is meant to further clarify the TechNet article http://technet.microsoft.com/en-us/library/hh456447.aspx Deploying a gateway server which links to a further explanation http://technet.microsoft.com/en-us/library/hh212810.aspx Authentication and Data Encryption for Windows Computers

More about certificates can also be found here:

Win2008 Enterprise CA: http://technet.microsoft.com/en-us/library/dd362553.aspx

Win2008 Standalone CA: http://technet.microsoft.com/en-us/library/dd362655.aspx

After the Windows Update process is finished, you can start installing Active Directory on the DC.

When you have installed and configured AD DS, add the AD CS role + the web site to request certificates.

And the rest is NNF (Next-Next-Finish).

Remove PKI and add Client / Server Authentication to Application Policies

From the GW server, the one that is not in the domain, you don’t trust the Enterprise CA by default.

That’s why you first have to get and install the Root CA certificate from the AD CS.

Add both My user account and Computer account – you’ll need both anyway

The certificate from the Root CA needs to be added in this list.

Open a web browser on the gateway server, and go to the CA Web service: http://OM12DC1/certsrv

Add the certsrv website to the Trusted Sites by going to internet options and under security choose Trusted Sites, and click on Sites to add this site.

Since the certsrv website uses ActiveX, change the security settings of Trusted Sites so that ActiveX is allowed.

Here we need to request the CA chain

If you don’t see these 2 popups, you need to enable ActiveX first.

The certificate is in the list now, meaning our workgroup gateway server will trust certificates issued by the Enterprise Root CA.

Now we need to request a certificate for our gateway server

Advanced request

Create and submit

Select the template that was created earlier, and fill in the Name and Friendly Name fields with the FQDN of your gateway server.

Since mine is in a workgroup, the NetBIOS name is sufficient.

And now the certificate is generated and we can install it

Done

But wait a minute… Installed, where???

We need to authenticate computers, and the certificate is imported in the personal certificate store.

So we need to open the Certificates MMC and copy the certificate from the personal store to the local computer store.

The certificate is now installed and you can verify everything is installed correctly by opening the certificate and checking if the certification path is ok.

On the Management Server, we also need to install a certificate. Since we have an Enterprise Root CA, integrated with AD, the root CA certificate is already trusted by our MS who is a domain member.

We can also request certificates in another way: we can request a new certificate from our CA directly from the MMC.

Click next

Select the certificate that we’ve created earlier

The extra information needed is the Common Name in the first box (OM12MS) and the FQDN in the bottom box with DNS.

And click Enroll to finish this

NOW we’re done

Now we have to approve the gateway to be able to communicate with the management server.

Copy the Microsoft.EnterpriseManagement.GatewayApprovalTool.exe and the corresponding Microsoft.EnterpriseManagement.GatewayApprovalTool.exe.CONFIG file from the support tools directory on your installation media to the installation path of your OpsMgr installation, in my case that’s C:\Program Files\System Center 2012\Operations Manager\Setup

1. Approve the gateway server: At the command prompt, run Microsoft.EnterpriseManagement.gatewayApprovalTool.exe /ManagementServerName=<managementserverFQDN> /GatewayName=<GatewayFQDN> /Action=Create

If the approval is successful, you will see The approval of server <GatewayFQDN> completed successfully.

Now you can install the gateway software by clicking the Gateway Management Server link in the setup splash screen

We did this, so we can continue the setup

Give the management group name - this can be found in the title bar of the console on the management server - and the management server name

The port number can be changed if desired. Only this 1 port needs to be open on the firewall, that’s the big advantage of using a gateway server!

Copy the MOMCertImport.exe tool to the gateway server, into the gateway installation path.

In my case, this is C:\Program Files\System Center Operations Manager\Gateway

Export

You’ll get a message that the action succeeded, and you can check progress in the Operations Manager event log.

Do the same for the gateway server:

Troubleshooting:

If you get event 21006, make sure the firewalls on the gateway and/or on the management server are not blocking communication

Don‘t forget to enable Agent Proxy for the gateway, as this one will act as a proxy for other systems connecting through the gateway server!

To check if it’s working, go to the Operations Manager Console – you should see something similar to this!!

HTH and a big thank you to my colleague Ingo for double-checking the certificate part!

/Danny

Do you or did you back in the days use your own code or a third party tool to create user accounts that did not update the userAccountControl attribute after the account was created?

Well then there's a change you might have accounts in your domain that are allowed blank passwords or even worse have accounts with blank passwords! 

Why?

Because user objects are allowed using blank passwords by default when created, something that must be handled afterwards. Unless that's in line with your security policy ;)

This is the default setting of userAccountControl on user objects at creation:

userAccountControl: 0x222 = (ACCOUNTDISABLE | PASSWD_NOTREQD | NORMAL_ACCOUNT); 

How does this setting affect my environment? 

Q: We have a password policy in our domain that does not allow blank passwords, are we protected from blank passwords?

A: No, this setting overrides the password policy in the domain or your fine grained password policy when you do reset password operations.  

So when is the "blank password" setting on user accounts effective: 

When users are delegated the permissions to do password resets on user accounts with ADS_UF_PASSWD_NOTREQD, they can set a blank password. 

A normal change password procedure by a user do not follow the ADS_UF_PASSWD_NOTREQD, it will follow the password policy in your domain or fine grained password policy if you got defined for the user.

So let say that an user with the delegate right to do password reset accidentally press OK in the password reset dialog box without the "User must change password at next logon" or someone in your organization with permissions to create user objects accidentally runs a script that sets blank password.  Then you will have accounts in you domain with no password.

How do I find accounts with ADS_UF_PASSWD_NOTREQD?

How will I know if any of the accounts in my domain have "password not required" set?

The easiest way to do it is to do a search with ADUC (Active Directory Users and Computers) mmc snap-in:

1. Right click the domain root.

2. Select Find....

3. In the Find: drop down box select Custom Search.

4. Click the Advanced tab.

5. In the Enter LDAP Query: field type: (&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=32)).

6. Click Find Now.

This will give you all accounts in the select domain that does not requires a password.

What are NETBIOSNAME$ accounts?

Some accounts should have this value so you might expect to find user accounts called  "Trust Short Domain Name"$ . ie. CORP$ or CHILDDOMAIN$.

These are trust accounts, located in the Users (CN=Users, + Domain DN) container, named after the NETBIOS domain name of the domain you share a trust with plus a dollar sign ($).

Leave these accounts alone, if you try to change the userAccountControl value alone for these accounts you will get Access Denied!

Here can you read about the trust account (TDO Passwords):

How Domain and Forest Trusts Work

http://technet.microsoft.com/en-us/library/cc773178(v=ws.10).aspx

How to create users?

To create users without allowing blank passwords you must deal with the userAccountContol values: 

Here you can read on how to create user accounts:

Creating a user (Windows) 

PASSWD_NOTREQD flag:

This Vbscript code example will create a user with ADS_UF_PASSWD_NOTREQD. The user will be allowed using blank passwords. 

This Vbscript code example manage the userAccountControl attribute. It removes both the disabled state and "password not required" setting: 

How do I know if I got blank passwords and how do I deal with it?

Well, you can run a script to test every account against a blank password or why not find users with passwords that don't comply with the password policy and remove the user setting for other users at the same time? :) 

There's a code-sample (RemoveUserPASSWD_NOTREQD.ps1) attached below that remove the ADS_UF_PASSWD_NOTREQD flag and If a user has a blank password the script will fail and report an error stating it does not follow the password policy for the domain, as long as you have a password policy in the domain that requires minimum length above zero characters.

If the script succeeds to remove the ADS_UF_PASSWD_NOTREQD flag  it will also report the status of the account, since if the account is also disabled it still could have a blank password. Something you will get aware of when you try to enable it.

If you try to enable an account that has no password you will get this:

You could test your environment with this code-sample and review the output.

Here is an example of output: 

This PowerShell script requires Active Directory Module for Windows PowerShell. 

What happens when I remove the ADS_UF_PASSWD_NOTREQD flag?

The afftect account can not get blank password at the next password reset, unless the password policy in the domain or fine grained password policy allow it!

Hopefully you do not have accounts with ADS_UF_PASSWD_NOTREQD.

You could still have accounts with blank passwords in case you had a domain password policy with no minimum password length.

To fix this you have to :

• make sure your password policies are in line with your security policy
• verify that users are required to change their passwords
• verify that users don´t have "Password never expires" ticked in.

Go and verify!

For those wanting to get rid of the SCCM MP error (introduced in the latest version 6.0.6000.3) "Failed to read %PROCESSOR_ARCHITECTURE environment variable from Win32_Environment WMI class", there is a hotfix available now:

http://support.microsoft.com/kb/2692929

More information, as always, can be found on Kevin Holman's blog: http://blogs.technet.com/b/kevinholman/archive/2011/09/30/mp-update-new-configmgr-2007-mp-version-6-0-6000-3-resolves-top-issues.aspx

HTH,

Danny

During the evening yesterday my daughter wanted to read some E-books on her new Windows RT slate. She wanted to borrow an E-Book from our local library in Sweden. I was expecting this to be an easy task and gladley tried to find a download link for Windows RT at the library hompage. I found every type of possiblity to read it on different types of Operating System, exept the Windows RT.

The main issue is that the main E-library system is using books protected with EPUB with DRM protection from Adobe. As the official statement from Adobe is that Windows RT is not a supported platform (http://blogs.adobe.com/digitalpublishing/supported-devices), this means that there is no offical Adobe way to borrow these books.

The workaround in this case is to use the Overdrive app (http://www.overdrive.com/news/new-overdrive-app-taps-power-of-windows-8-2/) This can directly downloaded from here (http://apps.microsoft.com/webpdp/app/overdrive-media-console/0c1b24d6-bf93-44da-90fb-601c6a99e379)

With this app you are now able to download the .acsm file from the library. To be able to read this DRM protected E-Book you will have to register an Adobe ID (http://www.adobe.com/account/sign-in.adobedotcom.html) and provide the required info to get your Adobe ID

You will also need to enter your Adobe ID into Overdrive which can be done through the 'Accounts' option in the Settings menu. Swipe in from the right of the screen to open the menu and select 'Settings'. Select 'Accounts' and then 'Authorize'. Enter your
Adobe ID and password.

Now you are ready to get the .acsm file from the library and open the E-book and start Reading the book.