Active Directory PowerShell: List items with “Protect object from accidental deletion” setting

Freshly posted for you on TNWiki: http://social.technet.microsoft.com/wiki/contents/articles/36088.active-directory-powershell-list-items-with-protect-object-from-accidental-deletion-setting.aspx

 


Introduction

Ever got in a situation where you as AD domain admin were blocked from
deleting items?

Or did you ever receive an “Access denied” when you tried to delete items
from AD, even with full admin rights?

Then you better check if AD has the “protect from accidental deletion”
activated on the object, container or OU…

In case you want to check a larger collection of items for this setting, it
quickly becomes complicated.

This article helps you to get an overview by using Powershell, and an export
of the impacted items to a CSV file.

As explained by : James ONeill (Windows Server 2008 Protection from Accidental Deletion)

“The functionality to prevent accidental deletion is not based on a new attribute in Active Directory.  It is enabled by ticking a check box on the Object tab of the particular object you wish to protect.  The Object tab is only visible when the Advanced Features option is selected from the View menu of Active Directory Users and Computers. When the tick box is checked the permissions on the object are changed. A “Deny” permission is created which stops deletion of the object.  “

 


Overview

This script finds all AD objects protected from accidental deletions.

 


Credits

This script uses logic that has been developed by:

 


Source references



Active Directory OU Permissions Report: Free PowerShell Script Download

 


Preventing Unwanted/Accidental deletions and Restore deleted objects in Active
Directory

 


Windows Server 2008 Protection from Accidental Deletion

 


Prerequisites

This script only runs if you can load the AD PS module eg. run the analysis
on a DC.

 


Downloads (Gallery)

 


Source Code

Full Version (with progress bar)

001002

003

004

005

006

007

008

009

010

011

012

013

014

015

016

017

018

019

020

021

022

023

024

025

026

027

028

029

030

031

032

033

034

035

036

037

038

039

040

041

042

043

044

045

046

047

048

049

050

051

052

053

054

055

056

057

058

059

060

061

062

063

064

065

066

067

068

069

070

071

072

073

074

075

076

077

078

079

080

081

082

083

084

085

086

087

088

089

090

091

092

093

094

095

096

097

098

099

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122


<##############################################################################
Author: Peter Geelen

Quest For Security

October 2016
https://identityunderground.wordpress.com

This script finds all AD objects protected by accidental deletions.

Credits: This script uses logic that has been developed by:

– Ashley McGlone, Microsoft Premier Field Engineer, March 2013, http://aka.ms/GoateePFE

– Source: https://gallery.technet.microsoft.com/Active-Directory-OU-1d09f989

LEGAL DISCLAIMER

This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment.

THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,

INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

We grant You a nonexclusive, royalty-free right to use and modify the Sample Code and to reproduce and distribute the object code form of the Sample Code,

provided that You agree:

(i) to not use Our name, logo, or trademarks to market Your software product in which the Sample Code is embedded;

(ii) to include a valid copyright notice on Your software product in which the Sample Code is embedded;and

(iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits, including attorneys  fees, that arise or result from the use or distribution of the Sample Code.

 

This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

##############################################################################>


#—————————————————————————–

#Source references


#—————————————————————————–


#Preventing Unwanted/Accidental deletions and Restore deleted objects in Active Directory

#abizer_hazratJune 9, 2009


#https://blogs.technet.microsoft.com/abizerh/2009/06/09/preventing-unwantedaccidental-deletions-and-restore-deleted-objects-in-active-directory/


#Windows Server 2008 Protection from Accidental Deletion

#James ONeill, October 31, 2007


#https://blogs.technet.microsoft.com/industry_insiders/2007/10/31/windows-server-2008-protection-from-accidental-deletion/


#—————————————————————————–

#Prerequisites: 


#this script only runs if you can load the AD PS module

#eg. run the analysis on a DC


#—————————————————————————–

cls

import-module activedirectory


#—————————————————————————–

#initialisation


#—————————————————————————–


#the CSV file is saved in the same directory as the PS file

$csvFile = $MyInvocation.MyCommand.Definition -replace ‘ps1’,‘csv’

$report = @()

#(*) Credits 

$schemaIDGUID = @{}


### NEED TO RECONCILE THE CONFLICTS ###

$ErrorActionPreference = ‘SilentlyContinue’

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter ‘(schemaIDGUID=*)’ -Properties name, schemaIDGUID |

 ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

Get-ADObject -SearchBase “CN=Extended-Rights,$((Get-ADRootDSE).configurationNamingContext)” -LDAPFilter ‘(objectClass=controlAccessRight)’ -Properties name, rightsGUID |

 ForEach-Object {$schemaIDGUID.add([System.GUID]$_.rightsGUID,$_.name)}

$ErrorActionPreference = ‘Continue’

#(*)


#—————————————————————————–

#Functions


#—————————————————————————–

function CheckProtection

{

    param($obj)

    $path = “AD:\” + $obj

    Get-Acl -Path $path | `

    Select-Object -ExpandProperty Access | `

    Where-Object {($_.ActiveDirectoryRights -like “*DeleteTree*”-AND ($_.AccessControlType -eq “Deny”)} | `

        #(*)

        Select-Object @{name=‘Object’;expression={$obj}}, `

        @{name=‘objectTypeName’;expression={if ($_.objectType.ToString() -eq ‘00000000-0000-0000-0000-000000000000’) {‘All’Else {$schemaIDGUID.Item($_.objectType)}}}, `

        @{name=‘inheritedObjectTypeName’;expression={$schemaIDGUID.Item($_.inheritedObjectType)}}, `

        #(*)

        ActiveDirectoryRights,

        ObjectFlags,

        AccessControlType,

        IdentityReference,

        IsInherited,

        InheritanceFlags,

        PropagationFlags

}


#—————————————————————————–

#MAIN


#—————————————————————————–

#add the top domain

$OUs = @(Get-ADDomain | Select-Object -ExpandProperty DistinguishedName)

#add the OUs

$OUs += Get-ADOrganizationalUnit -Filter * | Select-Object -ExpandProperty DistinguishedName

#add other containers

$OUs += Get-ADObject -SearchBase (Get-ADDomain).DistinguishedName -LDAPFilter ‘(|(objectClass=container)(objectClass=builtinDomain))’ | Select-Object -ExpandProperty DistinguishedName


#if you don’t want to scan the builtin container use line below instead of line above


#$OUs += Get-ADObject -SearchBase (Get-ADDomain).DistinguishedName -LDAPFilter ‘(objectClass=container)’ | Select-Object -ExpandProperty DistinguishedName


#set the target objects types to investigate


#including users, groups, contacts, computers

$ldapfilter = ‘(|(objectclass=user)(objectclass=group)(objectclass=contact)(objectclass=computer))’


#$ldapfilter = ‘(|(objectclass=user)(objectclass=group)(objectclass=contact)(objectclass=computer)(objectclass=Foreign-Security-Principal))’


#not included: Foreign-Security-Principal, msTPM-InformationObjectsContainer, msDS-QuotaContainer, lostAndFound,

$iSeqNo = 0

$OUCount = $OUs.Count

ForEach ($OU in $OUs

{

    $iSeqNo++

    $pct = ([int]($iSeqNo/$OUCount * 100))

    $activity = “Analyzing container: “+ $OU

    Write-Progress -activity $activity -status “Please wait” -percentcomplete $pct -currentoperation “now processing container $iSeqNo of $OUCount” -id 1

    #check the protection of the parent container

    $isProtected = 

    $isProtected = CheckProtection $OU

    if ($isProtected -ne $null) {$report += $isProtected}

    

    #Lookup the child target objects in the parent container

    $objects = Get-ADObject -SearchBase $OU -SearchScope OneLevel -LDAPFilter $ldapfilter | Select-Object -ExpandProperty DistinguishedName

    $iSubSeqNo = 0

    $ObjCount = $objects.Count

    

    #check the protection of the child objects

    ForEach ($object in $objects)

    {

        $iSubSeqNo++

        $iSubpct = ([int]($iSubSeqNo/$ObjCount * 100))

        $SubActivity = “Analyzing object: “+ $object 

        Write-Progress -activity $SubActivity -status “Please wait” -percentcomplete $iSubpct -currentoperation “now processing object $iSubSeqNo of $ObjCount” -ParentId 1 -id 2

    

        $isProtected = 

        $isProtected = CheckProtection $object

        if ($isProtected -ne $null) {$report += $isProtected}

    }

        Write-Progress -activity “Analyzing object completed.” -status “Proceeding” -Completed -ParentId 1 -id 2

}

$report | Format-Table -Wrap

$report | Export-Csv -Path $csvFile -NoTypeInformation

 

Light version (without progress bar)

001002

003

004

005

006

007

008

009

010

011

012

013

014

015

016

017

018

019

020

021

022

023

024

025

026

027

028

029

030

031

032

033

034

035

036

037

038

039

040

041

042

043

044

045

046

047

048

049

050

051

052

053

054

055

056

057

058

059

060

061

062

063

064

065

066

067

068

069

070

071

072

073

074

075

076

077

078

079

080

081

082

083

084

085

086

087

088

089

090

091

092

093

094

095

096

097

098

099

100

101

102


<##############################################################################
Author: Peter Geelen Quest For Security  October 2016

https://identityunderground.wordpress.com

This script finds all AD objects protected by accidental deletions.

Credits: This script uses logic that has been developed by:

– Ashley McGlone, Microsoft Premier Field Engineer, March 2013, http://aka.ms/GoateePFE

– Source: https://gallery.technet.microsoft.com/Active-Directory-OU-1d09f989

LEGAL DISCLAIMER

This Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment.

THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,

INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.

We grant You a nonexclusive, royalty-free right to use and modify the Sample Code and to reproduce and distribute the object code form of the Sample Code,

provided that You agree:

(i) to not use Our name, logo, or trademarks to market Your software product in which the Sample Code is embedded;

(ii) to include a valid copyright notice on Your software product in which the Sample Code is embedded;and

(iii) to indemnify, hold harmless, and defend Us and Our suppliers from and against any claims or lawsuits, including attorneys  fees, that arise or result from the use or distribution of the Sample Code.

 

This posting is provided “AS IS” with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm.

##############################################################################>


#—————————————————————————–

#Source references


#—————————————————————————–


#Preventing Unwanted/Accidental deletions and Restore deleted objects in Active Directory

#abizer_hazratJune 9, 2009


#https://blogs.technet.microsoft.com/abizerh/2009/06/09/preventing-unwantedaccidental-deletions-and-restore-deleted-objects-in-active-directory/


#Windows Server 2008 Protection from Accidental Deletion

#James ONeill, October 31, 2007


#https://blogs.technet.microsoft.com/industry_insiders/2007/10/31/windows-server-2008-protection-from-accidental-deletion/


#—————————————————————————–

#Prerequisites: 


#this script only runs if you can load the AD PS module

#eg. run the analysis on a DC


#—————————————————————————–

cls

import-module activedirectory


#—————————————————————————–

#initialisation


#—————————————————————————–


#the CSV file is saved in the same directory as the PS file

$csvFile = $MyInvocation.MyCommand.Definition -replace ‘ps1’,‘csv’

$report = @()

#(*) Credits 

$schemaIDGUID = @{}


### NEED TO RECONCILE THE CONFLICTS ###

$ErrorActionPreference = ‘SilentlyContinue’

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter ‘(schemaIDGUID=*)’ -Properties name, schemaIDGUID |

 ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

Get-ADObject -SearchBase “CN=Extended-Rights,$((Get-ADRootDSE).configurationNamingContext)” -LDAPFilter ‘(objectClass=controlAccessRight)’ -Properties name, rightsGUID |

 ForEach-Object {$schemaIDGUID.add([System.GUID]$_.rightsGUID,$_.name)}

$ErrorActionPreference = ‘Continue’

#(*)


#—————————————————————————–

#Functions


#—————————————————————————–

function CheckProtection

{

    param($obj)

    $path = “AD:\” + $obj

    Get-Acl -Path $path | `

    Select-Object -ExpandProperty Access | `

    Where-Object {($_.ActiveDirectoryRights -like “*DeleteTree*”-AND ($_.AccessControlType -eq “Deny”)} | `

        #(*)

        Select-Object @{name=‘Object’;expression={$obj}}, `

        @{name=‘objectTypeName’;expression={if ($_.objectType.ToString() -eq ‘00000000-0000-0000-0000-000000000000’) {‘All’Else {$schemaIDGUID.Item($_.objectType)}}}, `

        @{name=‘inheritedObjectTypeName’;expression={$schemaIDGUID.Item($_.inheritedObjectType)}}, `

        #(*)

        ActiveDirectoryRights,

        ObjectFlags,

        AccessControlType,

        IdentityReference,

        IsInherited,

        InheritanceFlags,

        PropagationFlags

}


#—————————————————————————–

#MAIN


#—————————————————————————–

#add the top domain

$OUs = @(Get-ADDomain | Select-Object -ExpandProperty DistinguishedName)

#add the OUs

$OUs += Get-ADOrganizationalUnit -Filter * | Select-Object -ExpandProperty DistinguishedName

#add other containers

$OUs += Get-ADObject -SearchBase (Get-ADDomain).DistinguishedName -LDAPFilter ‘(|(objectClass=container)(objectClass=builtinDomain))’ | Select-Object -ExpandProperty DistinguishedName


#if you don’t want to scan the builtin container use line below instead of line above


#$OUs += Get-ADObject -SearchBase (Get-ADDomain).DistinguishedName -LDAPFilter ‘(objectClass=container)’ | Select-Object -ExpandProperty DistinguishedName


#set the target objects types to investigate


#including users, groups, contacts, computers

$ldapfilter = ‘(|(objectclass=user)(objectclass=group)(objectclass=contact)(objectclass=computer))’


#$ldapfilter = ‘(|(objectclass=user)(objectclass=group)(objectclass=contact)(objectclass=computer)(objectclass=Foreign-Security-Principal))’


#not included: Foreign-Security-Principal, msTPM-InformationObjectsContainer, msDS-QuotaContainer, lostAndFound,

ForEach ($OU in $OUs

{

    #check the protection of the parent container

    $isProtected = 

    $isProtected = CheckProtection $OU

    if ($isProtected -ne $null) {$report += $isProtected}

    

    #Lookup the child target objects in the parent container

    $objects = Get-ADObject -SearchBase $OU -SearchScope OneLevel -LDAPFilter $ldapfilter | Select-Object -ExpandProperty DistinguishedName

    #check the protection of the child objects

    ForEach ($object in $objects)

    {

        $isProtected = 

        $isProtected = CheckProtection $object

        if ($isProtected -ne $null) {$report += $isProtected}

    }

}

$report | Format-Table -Wrap

$report | Export-Csv -Path $csvFile -NoTypeInformation

 

 


Disclaimer

LEGAL DISCLAIMER

This Sample Code is provided for the purpose of
illustration only and is not intended to be used in a production environment.

THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED “AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,

INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR  PURPOSE.

We grant You a nonexclusive, royalty-free right to use and modify
the Sample Code and to reproduce and distribute the object code form of the
Sample Code,

provided that You agree:

(i) to not use Our name, logo, or
trademarks to market Your software product in which the Sample Code is embedded;

(ii) to include a valid copyright notice on Your software product in which
the Sample Code is embedded; and

(iii) to indemnify, hold harmless, and
defend Us and Our suppliers from and against any claims or lawsuits, including
attorneys’ fees, that arise or result from the use or distribution of the Sample
Code.

This posting is provided “AS IS” with no warranties, and confers no
rights.


Note-to-self: DNS naming best practices for internal domains and networks

Just a few days ago, I’ve got a question from a customer regarding the DNS naming best practices for internal DNS and AD domains…

As it’s not a daily job to setup a new AD domain and internal DNS (from scratch…), so it might help to share the results of my investigation, that have lead to confirm my practical experiences.

Apparently it’s a pretty frequent topic on AD and network platforms. Plus there are some strict technical guidelines that apply here, even for internal DNS configurations…

The short answer, as best practice:

  • Microsoft strongly recommends to register a public domain and use subdomains for the internal DNS.
  • So, register a public DNS name , so you own it. Then create subdomains for internal use (like corp.pgeelen.be, dmz.pgeelen.be, extranet.pgeelen.be) and make sure you’ve got your DNS configuration setup correctly.

Below more detailed explanation. Luckily enough there is some nice reading material out there to prove the statement, so make sure you bookmark this page 😉

But first we need to clarify a few things…

AD Domain vs DNS name

The AD domain name is NOT the same as the DNS name, but they are linked.

AD Domain names are mainly used within AD operations, mostly LDAP queries for AD functionality, while DNS is rather a network level solution for name resolution on IP level (to solve the machines or application names to IP addresses).

Essentialy this difference allows you to use a ‘internal’, private AD domain name and use a public, registered DNS name.

When you look into discussions and documentation on this topic, you’ll also see that the AD domain short name is referred as NetBIOS Name (as in the AD logon name <DOMAIN>\<username>).

For example

  • AD Domain name: CORP
  • DNS name: corp.pgeelen.be

See here for more explanation: https://technet.microsoft.com/en-us/library/bb676377

You can also ‘unlink’ the AD domain name from the DNS name, then you get a disjoint namespace, as explained in previous link.

For Example

  • AD Domain naam : CORP
  • DNS naam: intranet.pgeelen.be

Check this forum discussion: https://social.technet.microsoft.com/Forums/windowsserver/en-US/f6ac34e8-4b35-4c3b-a60f-179f68d6eb24/ad-domain-name-vs-dns-domain-name?forum=winserverDS

And also: https://technet.microsoft.com/en-us/library/cc978018.aspx

Dummy DNS name vs official DNS name

In the past, lots of people chose to use a dummy, unofficial TLD (top-level-domain) for their internal network, likedomain.lan, domain.local of domain.internal (and also domain.internalhost)

But this can get you in serious trouble.

Because these names are not supported by internet standards, the most important RFC on this is: RFC 2606 (http://tools.ietf.org/html/rfc2606)

This RFC standard is very explicit on chosing domain names for voor private testing and documentation

  • .test
  • .example
  • .invalid
  • .localhost

But also for documentation some 2nd level domains are reserved

  • example.com
  • example.net
  • example.org

As you can see, these names are created for testing and not for production.

Plus, if the public naming standards change or additional names are released you might be using a name you don’t own and that can be routed to the internet, which conflicts with the initial use.

Therefore the technical conclusion is fairly straight forward: register a public DNS name and use it for your internal DNS resolution.

So the use of <yourinternaldomain>.be is technically correct but it doesn’t stop there.

There are some important consequences.

Allow me to take the discussion a step further.

You have to make a choice on the DNS zones:

  • using a single DNS zone
  • Using subdomains
  • using different DNS zones

 

Using a single namespace (for internal and external hosts)

Some customers use the same DNS zone for internal and external usage. But there are some important disadvantages:

  • mismatch between security zones (like intranet, extranet, dmz and) and DNS naming
  • when adding / merging domains the DNS is subject to redesign
  • less flexible, less automated DNS operations
  • conflict in authority with internal DNS and external DNS (managed by internet provider)

You might face some practical issues like:

  • conflicts in DNS,
  • instable operations and sub-optimal performance
  • network issues
  • complex configuration
  • less or no automated DNS operations, more manual operations
  • keeping DNS under control is less obvious

Plus, you’ll face some consequences regarding network security, by the lack of segregation of (DNS) duties.

So: Single DNS domain is absolutely not advised.

Using different DNS names and zones

It’s completely the opposite of the previous approach. From DNS level, this is fairly simple setup, but you need to duplicate or multiply DNS configurations. And from a user perspective it might be complex or confusing, or not transparent, and inconsistent

DNS sub-domains

This is a frequently used technique to use the same TLD (top level domain) and separate the zones by subdomain. Eg “intranet”, “extranet”, “DMZ” for ‘internal’ zones en just plain <domain>.<tld> for public DNS.

For example:

  • intranet.pgeelen.be or corp.pgeelen.be (if your AD is named ‘CORP’ )
  • extranet.pgeelen.be for applications or partner facing websites
  • DMZ.pgeelen.be for applications that need DMZ for data protection or publication,
  • and master suffix .pgeelen.be for public websites (managed by your Internet Provider)

The forum post I mentioned earlier discusses a technique called “DNS split brain”:

In fact you have one DNS name space, but with sub spaces per zone.

This is a bit more complicated setup as you need to make sure the DNS servers forward the requests to the applicable zones correctly.

And it does require some planning and cooperation with your internet provider.

Microsoft strongly suggests to work with subdomains, within a publicly registered TLD domain.

Check: Creating Internal and External Domains op https://technet.microsoft.com/en-us/library/cc755946(WS.10).aspx

Design Option Management Complexity Example
The internal domain is a subdomain of the external domain. Microsoft strongly recommends this option. For more information, see Using an Internal Subdomain. Easy to deploy and administer. An organization with an external namespace contoso.com uses the internal namespace corp.contoso.com.
The internal and external domain names are different from each other. For more information, see Using Different Internal and External Domain Names. More complicated than previous option. An organization uses contoso.com for its external namespace, and corp.internal for its internal namespace.

 

On top of that you need to be aware of a few rules regarding naming standards: https://support.microsoft.com/en-us/kb/909264

 

To conclude, please find some useful reference info in one spot below:

Note-to-self: Strenghten your Intune/SCEP with ADCS

Recently I got a question from a customer about SCEP.
SCEP as in “Simple Certificate Enrollment Protocol”, not “System Center Endpoint protection”.

Pretty important difference, although SC (System Center as in SCCM) is involved in this case.

Background:
customer investigating integration of ADCS (Active Directory Certificate Services) with Intune.

Case:
Customer found an interesting article: “Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests” (http://www.kb.cert.org/vuls/id/971035)

In short, the article mentions (quote):

“SCEP was designed for use “…in a closed environment” and is not well suited for MDM and “bring your own device” (BYOD) applications where untrusted users and devices are in use.

When a user or a device requests a certificate, the SCEP implementation may require a challenge password. It may be possible for a user or device to take their legitimately acquired SCEP challenge password and use it to obtain a certificate that represents a different user with a higher level of access such as a network administrator, or to obtain a different type of certificate than what was intended.”

In Windows Server 2012 R2 the Active Directory Certificate Services (AD CS), NDES supports a policy module that provides additional security SCEP.

Windows Server 2012 R2 AD CS NDES does not ship with a policy module. You must create it yourself or obtain it as part of a software solution from a MDM vendor.

Microsoft Intune DOES HAVE that module.

But how do you integrate your ADCS with Intune?
Well, here’s the interesting stuff, there is a bunch of interesting reading and even step-by-step guides available from one of our Microsoft colleagues.
Just to be clear: all credits go to the original authors of ALL these articles I point you to.

But I thinks the links below must be in your favorites collection.

The technical background info you can find on TechNet had an update, recently:

If you really want to dive into it, with practical hands-on, please check this out (credits to Pieter Wigleven)

Pieter has put quite some effort to document the procedures step-by-step with very interesting screenshots.
Enjoy and share!

New #FIM2010 R2 SP1 hotfix released to fully support Windows Server 2012 R2 ADDS (Build 4.1.3634.0)

Microsoft has released a very important hotfix for FIM2010 R2 SP1: full details at https://support.microsoft.com/kb/3048056. (FIM Build 4.1.3634.0)

As indicated in the article, Microsoft recommends that all customers apply this update to their production systems.

The most important fix in this hotfix is that FIM2010 R2 (SP1) now fully supports Windows Server 2012 R2 Active Directory Domain Services, both for domain and forest level.

Still an important condition for this support is that the FIM Synchronization Service must be installed only on

  • Windows Server 2008,
  • Windows Server 2008 R2,
  • or Windows Server 2012 member server.

FIM 2010 Server components must NOT be installed on a Windows Server 2012 R2 member server.

Only the PCNS component can be installed on a Windows Server 2012 R2 domain controller.

More information:

Note-to-self: Just Enough Administration Whitepaper

Source: https://gallery.technet.microsoft.com/Just-Enough-Administration-6b5ad370

Short URL: http://aka.ms/JEA

From the introduction: ”

In the current world of Information Technology, protective measures do not stop at the network edge. Recent news reports based on security breach post-mortems indicate the need to protect assets using measures that reduce administrative access. While the principle of least privilege has always been known to IT Security professionals, there is a need in the industry for a standardized method of constructing an operator experience that reduces access with a more sophisticated level of granularity than what is available in many traditional access control models.

Just Enough Administration (JEA) is a solution designed to help protect Server systems. This is accomplished by allowing specific users to perform administrative tasks on servers without giving them administrator rights, and then auditing all actions that these users performed. JEA is based on Windows PowerShell constrained runspaces, a technology that is already being used to secure administrative tasks in environments such as Microsoft Exchange Online.”

For the latest information, please see http://blogs.msdn.com/powershell/ and http://aka.ms/buildingclouds

Don’t need to tell you that you should definitely save these in your favorites. (Well, just did it… so no excuses..)

Note-to-self: Review, Refresh and Revitalize your Group Policy Skills – Updated for Server 2012

Source: http://blogs.technet.com/b/tangent_thoughts/archive/2013/02/02/review-refresh-and-revitalize-your-group-policy-skills-updated-for-server-2012.aspx

Group Policy Documentation Survival Guide.

Windows Server 2012 Group Policy Guide.pdf