Zoho Banner September 2011

I’m sometimes asked what the best practice is surrounding the Default Domain Policy and Default Domain Controllers Policy. Microsoft has some good guidance on this topic, but it’s not always clearly and consistently stated. Here’s a quick Q&A that might help.

 

Q. Is it ok to make changes to the DDP and DDCP GPOs, or should I leave them alone and create new policies?

 

A. The best practice recommendation from Microsoft is as follows:

 

  • ·    To accommodate APIs from previous versions of the operating system that make changes directly to default GPOs, changes to the following security policy settings must be made directly in the Default Domain Policy GPO or in the Default Domain Controllers Policy GPO:
  • ·    Default Domain Security Policy Settings:
    • o    Password Policy
    • o    Domain Account Lockout Policy
    • o    Domain Kerberos Policy
  • ·    Default Domain Controller Security Policy Settings:
    • o    User Rights Assignment Policy
    • o    Audit Policy

Source: Best Practice Guide for Securing Active Directory Installations (https://technet.microsoft.com/en-us/library/cc773164(v=ws.10).aspx)

 

So, that’s it!  If you want to apply other settings at the domain root level or to the Domain Controllers OU then you should create new GPOs and link them to the appropriate scope of management. The ordering of the GPOs shouldn’t really matter as you should have no overlapping settings. As a general rule of thumb, however, I would recommend assigning any new GPOs a higher precedence in case someone starts using the default GPOs for settings that are not on the “approved” list above. That way the new GPOs will win in any conflict.

 

Another reason to limit the settings in the default GPOs is to allow them to be re-created with minimal re-work in scenarios where they have gone missing or are corrupt and you don’t have a good backup.  The method by which you can re-create the GPOs is using a tool called DCGPOFIX.EXE (https://technet.microsoft.com/en-us/library/hh875588.aspx).  Bear in mind that this tool is a last resort following a major issue or disaster and you should really ensure you have good GPO backups, as per this article:

 

If you are in a disaster recovery scenario and you do not have any backed up versions of the Default Domain Policy or the Default Domain Controller Policy, you may consider using the Dcgpofix tool. If you use the Dcgpofix tool, Microsoft recommends that as soon as you run it, you review the security settings in these GPOs and manually adjust the security settings to suit your requirements. A fix is not scheduled to be released because Microsoft recommends you use GPMC to back up and restore all GPOs in your environment. The Dcgpofix tool is a disaster-recovery tool that will restore your environment to a functional state only. It is best not to use it as a replacement for a backup strategy using GPMC. It is best to use the Dcgpofix tool only when a GPO back up for the Default Domain Policy and Default Domain Controller Policy does not exist.

Source: https://support.microsoft.com/en-us/kb/833783

 

Q. We have disabled our DDP and DDCP GPOs and replaced them with new GPOs. Is that OK?

 

A. No, that’s not ok.  The GPOs have a fixed GUID and can be targeted directly using these by the “legacy APIs” mentioned above. 

 

31b2f340-016d-11d2-945f-00c04fb984f9: Default Domain Policy

6ac1786c-016f-11d2-945f-00c04fb984f9: Default Domain Controllers Policy

 

One well known application that directly modifies the Default Domain Controllers Policy is Microsoft Exchange.  The installer adds the Exchange Servers group to the “Manage Auditing and Security Log” User Right (also referred to as SACL right). So, if you disable or unlink the GPO this right (and potentially others like it) it will go missing and will cause problems for Exchange.

 

Q. Is it OK to rename the DDP and DDCP GPOs?

A. If you feel you must do this I don’t believe it will have any impact, other than it might confuse people when they look for them. I’ve seen some customers rename the GPOs to align them with their in-house naming convention. As mentioned above, these GPOs are targeted using their well-known GUIDs, which is why the rename shouldn’t cause an issue. 

 

You can find the renamed GPOs quite easily using the Group Policy cmdlets, e.g.

 

# Find the Default Domain Policy

Get-GPO -Guid 31b2f340-016d-11d2-945f-00c04fb984f9

 

# Find the Default Domain Controllers Policy

Get-GPO -Guid 6ac1786c-016f-11d2-945f-00c04fb984f9

 

Conclusion

Use the default GPOs for the approved specific purposes only.  If you have other settings you need for the same scope of management, create new GPOs and link them with higher precedence than the default GPOs. Under no circumstances should you disable or unlink the GPOs.  If you rename the default GPOs there should be no impact, but your mileage may vary.

 

 

You know you’re getting old when you come across a Usenet post you wrote almost 20 years ago. I came across this little memento while Googling for a much more recent item. Given the vintage of the post, I must have been referring to Exchange 4.0.  Exchange has come a long way since then, although I do kind of miss X.400.

x400_tony

PS. I’m still waiting for an answer to my question. :-)

Over the weekend I opened up my laptop to knuckle down to my chapter reviews for the upcoming update to the excellent Inside Office 365 for Exchange Professionals. If you don’t already have a copy I strongly recommend you make the investments. The E-book is detailed, well researched and written by those who really know their stuff.

But I’m drifting off topic. The nasty surprise for me was that my laptop keyboard didn’t appear to work. This was strange as I’m negotiated past the Ctrl+Alt+Del dialogue, which meant it wasn’t a hardware failure. At first I thought it must be a Windows 10 driver issue. In some of the pre-release builds I’d had issues with the mouse pad drivers and I thought the keyboard issue was something similar. After 10 minutes or so of fruitlessly tinkering with drivers I finally resorted to Google and found the solution quite quickly. It turns out the “Enable Slow Keys” setting, which is part of the Ease of Access keyboard settings, had somehow turned itself on. I was able to confirm this by pressing and holding down a key. The selected character appeared on the screen after a delay.

I’m still not sure how I managed to turn the setting on, but was relieved to be able to turn it off. If you have the same issue, type “filter keys” in the “Search the web and Windows” area and then select the “Ignore brief or repeated keystrokes” option. From there you can turn off “Enable Slow Keys” option, as shown in the screenshot below.

Enable Slow Keys

Hopefully this will help you if you run into the same issue.

Like that hipster beard you grew last summer, all good things must eventually come to an end. You will likely be aware that the end of extended support for Windows Server 2003 finishes on July 14th 2015. If you don’t know whether you still have 2003 boxes lurking in the dark recesses of your AD domain, you could try running the handy script below to flush them out.

The script looks for Window Server 2003 machine accounts that have logged on to the domain some time within the past 60 days – a good indicator that they are still active. It produces a CSV output for your perusal.

#########################################################
#
# Name: Find-W2K3StillActive.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 25/06/2015
# Comment: PowerShell 2.0 script to find active
# Windows Server 2003 computer accounts
#
#########################################################

## Define global variables
# Export file for storing results
$expfile = "c:\w2k3_still_active.csv"
# Define the header row for the CSV (we will create our own)
$header = "`"name`",`"os`",`"sp`",`"lastlogondate`""
# Consider any account logged on in the last x days to be active
$days = 60
$Today = Get-date
$SubtractDays = New-Object System.TimeSpan $days, 0, 0, 0, 0
$StartDate = $Today.Subtract($SubtractDays)
$startdate = $startdate.ToFiletime()
# LDAP filter settings
$filter = "(&(lastlogontimestamp>=$startDate)(operatingsystem=Windows Server 2003*))"

## Functions
Function Format-ShortDate ($fdate)
{
        if ($fdate) {
            $day = $fdate.day
            $month = $fdate.month
            $year = $fdate.year
            "$day/$month/$year"
        } # end if

} # end function

## Start doing things
# Import the AD module
ipmo ActiveDirectory
# Tidy up any previous copies of the export file 
if (test-path $expfile) {Remove-Item $expfile}
# Add the header row to the export file
Add-Content -Value $header -Path $expfile
# Create an array of computer objects
$active = Get-ADComputer -LDAPFilter $filter -pr *
# loop through the array
foreach ($w2k3 in $active) {
    # Grab the attribute values we need from the AD object
    $nm = $w2k3.name
    $os = $w2k3.operatingsystem
    $sp = $w2k3.operatingsystemservicepack
    $lt = Format-ShortDate $($w2k3.lastlogondate)
    $row = "`"$nm`",`"$os`",`"$sp`",`"$lt`""
    # Commit the row to the export file
    Add-Content -Value $row -Path $expfile
} # end foreach

## End script

Enjoy!

Unfortunately Active Directory doesn’t yet provide dynamic security groups in the way that, for example, Exchange provides dynamic distribution groups.  Sometimes it is useful to maintain a group’s membership based on a specific attribute, or set of attributes.  Here’s a quick Powershell example that shows how to maintain the membership based on the presence of a single attribute value.

You can download the script here: AttributeBasedGroupMembership

 

#########################################################
#
# Name: AttributeBasedGroupMembership.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 18/06/2015
# Comment: PowerShell 2.0 script to manage group 
# membership based on attribute values
#
#########################################################

# Import the AD module
ipmo ActiveDirectory

# Define arrays to be used for matching
$arratt = @()
$arrgp = @()

# Domain controller to be used
$dc = (Get-ADRootDSE).dnshostname
write-host "Using DC $dc for all AD reads/writes"

# Specify the OU where the accounts are located
$OUdn = "OU=Corp Users,DC=Contoso,DC=com"

# Find all the objects that have the specified attribute value
$AttUsrs = Get-ADUser -LDAPFilter "(extensionattribute1=Sales)" -SearchBase $oudn -Server $dc

# Specify the GUID of the group to use
# You could also use name of group (but this can be changed)
$grp = "7bbf64bc-46c7-4a90-9d58-7cb5eca35fce" # i.e. "Sales Team"

# Find all the group members
$grpusers = Get-ADGroupMember -Identity $grp -Server $dc

# Build arrays using the DN attribute value
$AttUsrs | % {$arratt += $_.distinguishedname}
$grpusers | % {$arrgp += $_.distinguishedname}


# Add to group membership (newly assigned attribute value)
foreach ($usr in $arratt) {
    if ($arrgp -contains $usr) {
        write-host "User $usr is a member of the group"
    }
    else {
        write-host "User $usr is not a member of the group - adding..."
        Add-ADGroupMember -Identity $grp -Members $usr -Server $dc
    } # end else
    Remove-Variable -ErrorAction SilentlyContinue -Name usr    
} # end foreach

write-host "`n"

# Remove from group (no longer has attribute value or has been manually added to group)
# Assumption here is that the attribute value is authoritative for the group's membership
foreach ($mem in $arrgp) {
    if ($arratt -contains $mem) {
        write-host "User $mem still has the attribute value.  Nothing to do"
    } # end if
    else {
        write-host "User $mem does not have the attribute value.  Removing from membership..."
        Remove-ADGroupMember -Identity $grp -Members $mem -Server $dc -Confirm:$false
    } # end else
    Remove-Variable -ErrorAction SilentlyContinue -Name mem
} # end foreach

 

To ensure the script is run regularly, you would likely want to call it from a scheduled task.

 

 

You now have the ability to provide product feature requests and changes relating to Windows Server that go direct to the Product Group.  Not only that, but you can build a base of voter support to drive your suggestions across the line.

windowsserver.uservoice.com

I really like this concept as it removes the difficulties associated with getting your voice heard by those that really matter.

 

This article explains how to link your O365 tenant to an existing Microsoft Azure subscription, so that you can manage your O365 users from within Azure. Why would you want to do this? Well, perhaps you just want to centralise your administration functions, but it also gives you other benefits, such as the ability to assign Multi-Factor Authentication (MFA) and to control the cloud applications to which the users have access.

Here’s how I did it…

I have an Office 365 Small Business tenant as well as a Microsoft Azure account that I fund through my MSDN subscription’s monthly credit. Until a couple of months ago I managed these as completely separate entities, logging in with separate credentials for each. Then a friend (thanks Kev!) sent me some information on how to link the O365 directory to my existing Azure account. The process is made possible by the fact that all O365 tenant identities are stored in Azure Active Directory (AAD). Here’s a brief overview of the process:

In this example I manage my existing Azure subscription using my Microsoft Account (formerly Windows Live ID) named passport@activedir.org.  My O365 tenant is named Badger Lafarge (badgerlafarge.onmicrosoft.com)

1. Sign in to Microsoft’s Azure Management Portal with your Account Administrator account, e.g. passport@activedir.org

2. Select Active Directory from the left hand menu bar.

3. Choose New from the bottom menu bar.

custom_create

4. Select APP SERVICES->ACTIVE DIRECTORY->DIRECTORY->CUSTOM CREATE

5. Choose Existing Directory from the drop down list

existing_directory

 

existing_directory2

6. When re-directed to the sign-in page, sign-in with your O365 admin account credentials

sign_in_o365

7. Select continue when prompted and then sign back in with your Azure Account Administrator account

confirm

8. You should now see your O365 tenant listed as a new directory (see below)

aad_O365_tenant

 

That’s it! At this point you are ready to manage your O365 accounts via the Azure Portal (or via Powershell of course).

In a follow-up article I will explain how to enable these accounts for multi-factor authentication (MFA).

 

 

 

 

 

The smartphone I had before I bought my Nokia Lumia 930 was a Samsung S3. I changed phones after the S3 got run over by a car (a short, but dull, cautionary tale not worth relating here). The client I was working for at the time I still had the S3 had a BYOD option whereby you could hook up to their Exchange service via Exchange ActiveSync. It seemed like a sensible thing to do. The only snag was the EAS policy that was pushed out included device encryption. As soon as my S3 was encrypted it ran like a dog. A rotund, geriatric, three-legged dog. I couldn’t live with that, so I opted out of their service and decrypted the device.

Yesterday I was browsing my Lumia 930 settings to see if encryption was an option. I couldn’t see it, so started searching the Interweb for information. Here’s what I found…

“The Windows Phone OS supports using BitLocker technology to encrypt all user data stored locally on internal data partitions. This helps to protect the confidentiality of local device data from offline hardware attacks. If a phone is lost or stolen, and if the user locks their device with a PIN, device encryption helps make it difficult for an attacker to recover sensitive information from the device.

When device encryption is enabled, the main OS and internal user data store partitions are encrypted. SD cards that are inserted in the phone are not encrypted….

….Unlike BitLocker for desktop Windows, there is no recovery key backup and no UI option for end users to enable or disable device encryption on Windows Phones. Microsoft Exchange servers and enterprise device management servers cannot disable device encryption after it has been enabled.”

Source: https://dev.windowsphone.com/en-US/OEM/docs/Phone_Bring-Up/Secure_boot_and_device_encryption_overview

This is some good info, and apparently not well known, given the paucity of results from my searches.

Given that there is no UI for device encryption, the only known methods to enable it via a push from Exchange ActiveSync or an MDM device policy.

When I applied a policy forcing encryption to my Lumia 930, the only way I could determine whether encryption was enabled was via the Storage Sense app. The “After” picture below shows the encryption state. Blink and you’ll miss it.

 

Before

Before

After

After

It is a little worrying that there is no way to decrypt the device. On the other hand there doesn’t seem to be a massive performance hit resulting from the encryption, so I’m happy to live with it.

 

 

It seems that a couple of weeks ago my standalone Exchange Online Protection (EOP) configuration was changed without me being involved. Basically, it looks like my default Accepted Domain was changed from type “Internal Relay” to “Authoritative” without my knowledge or consent.

The first I knew of this was when I noticed my on-premises mail server was no longer receiving email. The current usage is low, so I didn’t notice it for a couple of weeks. After some troubleshooting I pinned the problem down to the fact that the Accepted Domain was showing as “Authoritative”. After changing it back to “Internal Relay” mail started getting delivered to my on-prem server almost immediately.

Accepted Domains

I have no delegated admins for this service, so nobody could have gone rogue on me. I have also checked the admin audit logs and the only entries shown for modifying the Accepted Domains configuration are a) when I originally set it up last September and b) when I changed it back yesterday. Here are a few screenshots to show the evidence.

Firstly the graph below shows when mail stopped being received…

graph

 

…then the audit entries showing when I made modifications to the mail.activedir.org Accepted Domain. It only shows the two entries. The first was when I set up the service last September and the second was when I made the change from “Authoritative” to “Internal Relay”yesterday.

 

EOP_audit2

 

 

EOP_audit1

It looks like I don’t have access to the external admin audit log report. It doesn’t appear in my EAC view (see below), so perhaps it is simply not available to EOP-only subscriptions. This might have been insightful as the the log apparently shows actions performed by datacentre administrators, which is where I believe the change was made.

 

Audit_View

Given the external admin audit log report wasn’t available via the EAC, I thought I would try to invoke it via Powershell. All I got from the output was the changes that I had made in the portal, i.e. no external admin entries.

 

PS C:\> Search-AdminAuditLog -ExternalAccess $true

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/mail.activedir.org
CmdletName         : Set-AcceptedDomain
CmdletParameters   : {MatchSubDomains, Identity, DomainType}
ModifiedProperties : {AcceptedDomainFlags, AcceptedDomainType}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 5/03/2015 1:44:26 a.m.
OriginatingServer  : DB3FFO11WS056 (15.01.0099.000)
Identity           : e7054efb-d9f5-461a-9c85-08d224fd0c3a
IsValid            : True
ObjectState        : New

PS C:\> $now = get-date

PS C:\> $start = $now.AddYears(-1)

PS C:\> Search-AdminAuditLog -ExternalAccess $true -StartDate $start -EndDate $now

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Transport Settings/FE Outbound
CmdletName         : New-OutboundConnector
CmdletParameters   : {TlsDomain, CloudServicesMailEnabled, TlsSettings, Enabled...}
ModifiedProperties : {ConfigurationUnit, SmartHostType, Id, OrganizationId...}
Caller             : tony@fisheaglelimited2014.onmicrosoft.com
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 7/09/2014 8:57:44 p.m.
OriginatingServer  : AM1FFO11WS040 (15.00.1010.011)
Identity           : ec85e346-1d12-4ab0-2067-08d198f581a9
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Transport Settings/FE Inbound
CmdletName         : New-InboundConnector
CmdletParameters   : {SenderIPAddresses, CloudServicesMailEnabled, RestrictDomainsToCertificate, Enabled...}
ModifiedProperties : {ConfigurationUnit, Id, OrganizationId, RawName...}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 8/09/2014 1:17:15 a.m.
OriginatingServer  : AM1FFO11WS002 (15.00.1019.000)
Identity           : 50f7f697-a501-4106-56a9-08d19919c2fb
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/FE Outbound
CmdletName         : Set-OutboundConnector
CmdletParameters   : {TlsDomain, CloudServicesMailEnabled, Identity, TlsSettings...}
ModifiedProperties : {RecipientDomains, RecipientDomainsEx, SmartHosts}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 8/09/2014 1:19:30 a.m.
OriginatingServer  : DB3FFO11WS013 (15.00.1019.000)
Identity           : 9f184a42-929c-4a98-54c8-08d1991a134d
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/mail.activedir.org
CmdletName         : Set-AcceptedDomain
CmdletParameters   : {MatchSubDomains, Identity, DomainType}
ModifiedProperties : {AcceptedDomainFlags, AcceptedDomainType}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 8/09/2014 1:24:06 a.m.
OriginatingServer  : AM1FFO11WS002 (15.00.1019.000)
Identity           : 55b909e6-abbd-43af-8c21-08d1991ab767
IsValid            : True
ObjectState        : New

RunspaceId         : 4e7bfd93-6f40-493b-b294-4f936506f863
ObjectModified     : FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/fisheaglelimited2014.onmicrosoft.com/Configuration/mail.activedir.org
CmdletName         : Set-AcceptedDomain
CmdletParameters   : {MatchSubDomains, Identity, DomainType}
ModifiedProperties : {AcceptedDomainFlags, AcceptedDomainType}
Caller             : tony@mail.activedir.org
ExternalAccess     : 
Succeeded          : True
Error              : None
RunDate            : 5/03/2015 1:44:26 a.m.
OriginatingServer  : DB3FFO11WS056 (15.01.0099.000)
Identity           : e7054efb-d9f5-461a-9c85-08d224fd0c3a
IsValid            : True
ObjectState        : New

 

I’ve opened a support incident with Microsoft about this, so I’ll post a follow-up here when that it resolved.

Anyone else out there experienced something similar?

 

 

 

The default location for newly provisioned user and computer objects are (respectively) the Users and Computers containers.  Since Windows Server 2003 Active Directory the option has been available to redirect these to OUs that you specificy.  Why would you want to do this?  Well, the Users and Computers containers are just that – container objects and not OUs.  You can apply Group Policy to OUs but not to containers. 

 As an example, you might have important security settings such as AppLocker application whitelisting that you apply to your computers via GPOs.  If you have computer objects in the default Computers container they will not be picking up those policies.

 I recommend to all my customers that they redirect the Users and Computers containers to OUs that are locked down with highly restrictive Group Policies.  This measure effectively forces the admins to move those objects to where they should be located in the OU structure.  The most well-known method of performing the redirection is to use the redirusr and redircmp utilities that are built-into the operating system.  The process is described on Technet (https://technet.microsoft.com/en-us/library/cc772758(v=ws.10).aspx)

 Of course we now have PowerShell as an alternative option.  I thought it would be fun to see how easy it would be to perform the redirection using a script.  Here’s what I came up with (seems to do the job).

 

## Specify the new targets for redirection
$dnc = (Get-ADRootDSE).DefaultNamingContext
# Users
$newusers = "OU=Redirected Users," + $dnc
# Computers
$newcomps = "OU=Redirected Computers," + $dnc

# Get the current targets (from wellKnownObjects attribute)
$wkos = Get-ADObject -Identity $dnc -pr wellKnownObjects `
| select -ExpandProperty wellKnownObjects

# Find the Users container value in the attribute
$curuwko = $wkos | ? {$_ -like "*CN=Users,*"}
# Split the value into its constituent parts
$datusers = $curuwko.split(":")

# Find the Computers container value in the attribute
$curcwko = $wkos | ? {$_ -like "*CN=Computers,*"}
# Split the value into its constituent parts
$datcomps = $curcwko.split(":")

# Build the new value for Users
$newuwko = $datusers[0] + ":" + $datusers[1] + ":" + $datusers[2] + ":" + $newusers
# Build the new value for Computers
$newcwko = $datcomps[0] + ":" + $datcomps[1] + ":" + $datcomps[2] + ":" + $newcomps

## Replace the old values with the new
$dc = (Get-ADDomainController).name
Set-ADObject $dnc -add @{wellKnownObjects = $newuwko} `
-Remove @{wellKnownObjects = $curuwko} -Server $dc
Set-ADObject $dnc -add @{wellKnownObjects = $newcwko} `
-Remove @{wellKnownObjects = $curcwko} -Server $dc