Skip to Content.
Sympa Menu

ad-assurance - [AD-Assurance] RE: Action Item from 3/22 (AD password store replication)

Subject: Meeting the InCommon Assurance profile criteria using Active Directory

List archive

[AD-Assurance] RE: Action Item from 3/22 (AD password store replication)


Chronological Thread 
  • From: "Amenya, Lee" <>
  • To: "" <>
  • Subject: [AD-Assurance] RE: Action Item from 3/22 (AD password store replication)
  • Date: Thu, 28 Mar 2013 21:48:44 +0000
  • Accept-language: en-US
  • Authentication-results: sfpop-ironport04.merit.edu; dkim=pass (signature verified)

Folks,

 

Below is my findings about password store replication

1.       The domain controllers use Kerberos security to secure (authenticate and encrypt) the replication traffic between the domain controllers (IP-RPC). SMTP replication is optional and supported only for inter-site replication and restricted only to non-domain data (schema, configuration, and global catalog updates), it also requires a PKI infrastructure (CA) when used over inter-site links.

2.       Password Changes and urgent notifications are done directly to the PDC emulator, then propagated to the other domain controllers using normal replication, if the PDC is not available, the normal replication schedule is used  

3.       When read only domain controllers are used, there is a password caching policy that need to defined to restrict (allow/deny) the list/groups of passwords that can be cached on the domain controller. ** Recommended configuration is no accounts cached

4.       For AES 128 & 256 Kerberos protocol support. In order for the TGT to be issued using AES, the domain functional level has to be Windows 2008 or higher and the password needs to be changed after the domain functional level has been raised.

5.       For inter-site replication across a firewall where Kerberos usage across the firewall is not preferred, IPSec can be used to encapsulate the connection. IPSec can also be used in conjunction with Kerberos to further secure the replication traffic.

 

I’ve been going through the documentation, but I’ve not been able to find a clear definition of what the approved encryption algorithms for the IAP should be.  If the minimum requirement is using AES, then the recommendation would be to ensure that the functional domain level, is at least at 2008 Functional Level.

 

Miscellaneous references:

How Active Directory Replication model works - http://technet.microsoft.com/en-us/library/cc772726 (v=WS.10).aspx

Understanding Replication between sites - http://technet.microsoft.com/en-us/library/cc771251.aspx

Password Replication Policy - http://technet.microsoft.com/en-us/library/cc730883(v=ws.10).aspx

Understanding Active directory domain services (AD DS) Functional Levels - http://technet.microsoft.com/en-us/library/understanding-active-directory-functional-levels (v=ws.10).aspx

Active Directory Replication Over firewalls - http://social.technet.microsoft.com/wiki/contents/articles/584.active-directory-replication-over-firewalls.aspx#Enacpsulating

 

Let me know if you have any questions.

 

Sincerely,

Lee Amenya

Prog. Analyst

Administrative Computing and Telecommunications/Information Technology Infrastructure(ACT/ITI)

X27764

 

 

From: [mailto:] On Behalf Of Ann West
Sent: Friday, March 22, 2013 11:38 AM
To:
Subject: [AD-Assurance] Action Items and Notes from 3/22

 

The notes from today's call are available at:

 

Action Items

Ron will upload Bit Locker information to the wiki.

Michael to update the existing rows to reflect today's discussion.
Lee will check into recommendations for AD password store replication.
Mark to fill in 4.2.3.6.2 and 3.
Eric to fill in 4.2.5.1, 4.2.5.2, 4.2.8.2.1 and review if there are other gaps besides protected channels.

 

Next Call

Friday March 29 at Noon ET

Agenda: Ron's AM, updates to AIs and impacts on the matrix, next matrix criteria

 

Best,

Ann

 

 

 




Archive powered by MHonArc 2.6.16.

Top of Page