MCTS 70 – 649 Configuring additional Active Directory Server Roles

Configure Active Directory Lightweight Directory Service (AD LDS)

Limitations

  • No global catalog support
  • No group policies
  • Doesn’t store Windows Security principles

Benefits

  • Same technology as AD DS; multimaster replication, ESE database engine, stores user, group or application data
  • AD LDS can run on a domain member or a standalone server
  • AD LDS uses the same ports as AD DS  – LDAP TCP/UDP 389 and LDAP SSL TCP 636 (use caution when AD LDS is installed on a domain member)
  • Increased scalability due to separation of application and network services
  • Authentication and access control using Windows Security principles
    • Uses local or domain user accounts with NTLM and kerberos respectively
  • simple LDAP authentication
    • Uses local or domain user accounts but authentication is sent in clear text; in production you would need to secure LDAP with SSL
  • AD LDS proxy authentication
    • Uses AD DS passwords with AD LDS user accounts. The AD LDS instance must either be installed on a domain member or a trust relationship must be in place

Use scenarios

  • DMZ web authentication; web sites and web services
  • Application logons
  • Application configuration storage
  • E-Mail directory (Exchange edge transport)
  • Distributed applications
  • Departmental level identity requirement
  • 3rd party applications that extend the AD schema
  • Development purposes

AD LDS naming contexts

  • Configuration
    • AD LDS replication schedules, replica sets, partitions and instances
  • Schema
    • object definitions i.e. object types and attributes
  • Application
    • defined by the user; contains application data

AD LDS tools

  • Wizard (ADAMInstall.exe)
    • New instances
    • creating replicas
  • LDP.exe
    • Adding, modifying, viewing and deleting objects
  • ADSIedit.exe
    • Adding, modifying, viewing and deleting objects
  • AdamSync.exe
    • Synch objects from AD DS to AD LDS
  • DsAcls.exe
    • query or change security attributes of objects
  • Ldifde.exe
    • Used to import and export data from and to text files
  • Csvde.exe
    • Used to import and export data from and to text files
  • ADSchemaAnalyzer.exe
    • Copies schema from AD DS to AD LDS
  • DsdbUtil.exe
    • Backup and authoriative restores of AD LDS data
    • Move AD LDS data files
    • Change AD LDS service account and or ports
    • List AD LDS instances
  • Ad Schema Snapin
    • View and manage schema objects
  • AD Sites and Services Snapin
    • Manage replication scopes for AD LDS

If you are connecting to LDAP using simple bind then consider using LDAPS i.e. LDAP over SSL; Port 636 by default. This is because simple bind sends username and password credentials in clear text.

Installing AD LDS

The partition must use a distinguished name (DN) e.g. CN=AppPartition1,DC=domain,DC=com.

Consider using high ports if AD LDS is installed within a domain, this stops conflicts with AD DS tools.

Role installation:

  • GUI
    • Server manager > server roles > AD LDS > Next > Install > Close
  • CLI
    • SERVER CORE: start /wait ocsetup DirectoryServices-ADAM-ServerCore

Instance installation and configuration:

Unattended installs of AD LDS require an answer file, example here, to use it run c:\windows\adam\adaminstall.exe /answer:answerfile.txt or run the AD LDS wizard. It is best practice to create separate instances when applications have differing schema requirements. Also consider using separate configuration sets when an application has strict isolation requirements; a configuration set is a group of AD LDS instances that replicate a common schema and configuration partition.

Uninstalling AD LDS

To uninstall an AD LDS instance go to control panel > programs and features > select the ad lds instance.

Service Connection Point (SCP)

AD LDS will attempt to create a Service Connection Point (SCP) in Active Directory if AD LDS is being installed on a domain member and the AD LDS service account has Create Child rights on the computer object i.e. the computer object which defines the computer where AD LDS is being installed. The service account should have read and write ServicePrincipalName granted to the principal SELF.

Service account guidelines

  • Domain or local account; depends on where AD LDS is located; user should be a standard user.
  • Account name should match the instance name
  • use a complex password
  • set password never expires and user cannot change password
  • assign user account log on as a service user right
  • assign generate security audits user right

AD LDS Replication

Replication uses:

  • Fault tolerance/High availability/Load balancing – multiple copies of an instance on multiple servers. distributed locally and geographically

AD LDS replication is configured using the sites and services snap-in; by default this binds to AD DS, right click the root node > change domain controller > enter the AD LDS instance server name and port e.g. server1:389. The replication topology is automatically generated using the Knowledge Consistency Checker (KCC), in the same way AD DS replication topologies are built.

To recalculate the inbound replication topology run repadmin /kcc; this is recalculated every 15 minutes by default.

AD LDS and AD DS integration

Adamsync is used to synchronise data from AD DS to the AD LDS; the AD LDS schema must support the AD DS objects. NOTE: adamsync does not synchronise passwords. The best example I think of AD DS and AD LDS integration is Exchange Server; the edge transport uses AD LDS to store the valid email addresses of that particular organisation; these email addresses are replicated from AD DS periodically.

References

Implementing LDAPS (LDAP over SSL)

LDAP over SSL (LDAPS) Certificate

Understanding LDAP Security Processing

Service Connection Points (SCPs) and ADAM/AD LDS

Configure Active Directory Rights Management Service (AD RMS)

AD RMS is designed to protect your intellectual property using AD DS, AD CS and can utilise AD FS to extend AD RMS beyond the firewall.

AD RMS requires

  • Active Directory Rights Management Service (AD RMS) server role
  • Microsoft SQL Server (for test and development the Windows internal database is ok)
  • Active Directory Directory Services (ADDS) server role
  • Digital certificates for authentication and authorisation.
  • IRM aware applications such as office 2003, SharePoint and Exchange Server
  • preferably IIS 7 to provide web services with ASP.NET
  • MSMQ  for distributed environments
  • Consider CNAMEs for the licensing and certifications Urls
  • If AD RMS is installed in the same domain as its users then those users will require email addresses; email addresses are also required for trusted user domains to function correctly i.e. each user account should be authenticated by their own domain controllers.
  • The installer account should be enterprise admin in order to create the SCP
  • 3rd party SSL certificate for the web sites
  • If kerberos authentication is being used then set the useIISAppPoolCredentials to true and create s Service Principal Name for the AD RMS service account.
  • Client computers should be Vista SP2 or later in order for AD RMS template updates to deployed seamlessly.

Deployment Scenarios

  • Single server – licensing, certfiication and database all together
  • multiple servers – multiple AD RMS clusters require the AD DMS database be hosted outside the cluster
  • Extranet (DMZ) – licensing and certification Urls should be publically accessible
  • Multiple forest – requires AD RMS in each forest, the trusted user domain trust policies of each respective AD RMS should be deployed to the other AD RMS, anonymous access to the license.asmx and servicelocator.asmx. The forest schemas should be extended to include the msExchOriginatingForest attribute; use ldifde to accomplish this and create contact objects and distribution groups
  • AD RMS with AD FS – requires a AD RMS in the resource forest and federation servers in each respective forest. The federation support role service should be installed on the AD RMS and the federated identity support trust policy enabled.
  • licensing-only – licensing component is installed separately to the root component

Windows Server 2008 Enhancements

  • Intergation with AD FS to extend rights management beyond the firewall
  • Dependencies components are installed when the role is installed
  • MMC snap-in administration
  • Self enrolled Server Licensor Certificate (SLC) grants the server the right to participate in the AD RMS structure
  • Built in roles allow delegation of AD RMS privileges without granting extra privileges
    • Enterprise Admins – manage all aspects of AD RMS
    • Template Admins – create, modify and export rights policies
    • Auditors – manage logs and reports
    • Service – AD RMS service account

User rights and certificates

AD RMS uses certificates to identity trusted entities that create and publish rights enabled content. When rights enabled content is published a publishing licence is integrated into the content; this licence is permanent and does not require access to AD RMS to provide content protection.

AD RMS certificates:

  • SLC – self signed certificate generated when the first root cluster is installed
  • Rights Account Certificate (RAC) – generated when a trusted user (who has a email enabled account) accesses rights-protected content; this certificate contains both the public and private keys
  • Client Licensor Certificate (CLC) – CLCs are requested when a user launches an AD RMS enabled application and already has a RAC. The CLC allows the user to apply policies whether online or offline.
  • Machine certificate – created the first time a user uses a AD RMS enabled application; this process is managed by the AD RMS client and AD RMS cluster.
  • Publishing licence – created when a user saves content in a rights protected mode; lists what rights users have.
  • Use licence – assigned to user who open rights protected content; the use licence is tied to the RAC certificate

Trust policies:

  • Windows Live ID trusts – allows Live ID users to use rights-protected content
  • Federated trusts – used with AD FS
  • Trusted publishing domains – used to issue use licenses for content protected by another AD RMS
  • Trusted user domains – used to process requests for other AD RMS located in other forests

Super groups are used to allow a defined set of users access to all protected content; this allows these user accounts to recover or modify data e.g. recover rights-protected data encrypted by another user.

AD RMS clients use AD DS SCPs, Urls in the licenses or registry keys.

References

Active Directory Rights Management Services

Configure the read-only domain controller (RODC)

RODCs limits the credentials exposed on branch office domain controllers; the credentials are controlled by Password Replication Policies (PRP) thus if a RODC is stolen the impact is limits to just those credentials. The RODC caches the credentials after the first authentication request and if the user or users group is defined on the allowed list.

The allowed list can contain users, groups and computers; there is also a denied list which can contain users, groups and computers; the denied list takes precedence over the allowed list. These lists are defined on the RODC computer object in AD DS. The advanced button within the PRP tab allows you to view cached account and non-cached accounts.

It is as important to include branch computer accounts as well as branch users accounts; if you don’t the computer accounts Ticket Granting Ticket (TGT) will not be cached, so when the user comes to logon and the site-to-site link is down, that user will not be able to logon, as the computer will not be able to send a Ticket Granting Service (TGS) request for that user.

An alternative to caching credentials as and when they’re needed is the prepopulate cache option; this allows you to define user and computer accounts the RODC should cache.

Useful command line tools:

repadmin /prp view [rodc name] allow – shows the allowed list

repadmin /prp view [rodc name] deny – shows the denied list

repadmin /prp view [rodc name] auth2 – shows the accounts that have authenticated; the most recent objects authenticated can be viewed via a writeable domain controller.

repadmin /prp view [rodc name] reveal – shows the accounts that have been cached

If the RODCs is location is insecure then it maybe worth considering using BitLocker for full drive encryption or syskey to encrypt the Security Account Manager (SAM) database. The disadvantage of BitLocker in a branch office would be having to enter a password on reboot; maybe this could be overcome using out-of-band access.

Administrator role separation

The RODC doesn’t integrate any local accounts with Active Directory so the local administrator account can be used to delegate administrative privileges out to branch admins without compromising Active Directory security. To add a user to the local administrators or any other local role open a command prompt > dsmgmt > local roles > add {domain\username} administrators. To list roles:  type list roles from within the same context.

Unidirectional replication

RODC use unidirectional replication i.e. from AD DS to RODC.

Deployment requirements

RODCs require at least one Windows Server 2008 writeable domain controller; If the forest contains Windows Server 2003 domain controllers then adprep /rodcprep must be run to enable RODC deployment but also allows RODCs to replicate the DNS application partition. adprep /rodcprep can be run on any computer that as access to the domain naming master and the infrastructure operations master. The forest and domain functional level must be at least Windows Server 2003 to support RODCs. You can check forest and domain functional level by opening the domain and trust snap-in > right click the forest root > properties > general.

RODC DNS

RODCs have a read only copy of DNS; this stops rogue DNS records poisoning your DNS zone.

If the branch office clients use dynamic DNS updates, these updates are referred up to a writeable domain controller and replicated back down to the RODC.

It is important that the Windows Server 2008 writeable domain controller hosts both Active Directory and DNS, if the RODC is to receive domain and DNS updates.

Forest and Domain Functional levels

You should not arbitrarily raise the functional level of the forest or domain, only raise them to meet your feature requirements.

RODC installation

RODCs can be installed on a full install or core install of Windows Server 2008; the install can be interactive or unattended and delegated; the delegated option requires the computer where the RODC role be installed be a member of a workgroup.

Full install: dcpromo > (advanced mode allows you to configure password replication policies) > existing forest > existing domain > {domain name} > {domain admin credentials} > select domain > select site > check RODC check box > complete wizard.

Core install: dcpromo /unattend:c:\answerfile.txt; example here

Delegated install: pre-create read-only domain controller account: within domain controller container right click > pre-create read-only domain controller account… > follow wizard or

dcpromo.exe /CreateDCAccount /ReplicaDomainDNSName:[FQDN] /unattend:C:\Users\Administrator\Desktop\[unattendStage1].txt

logon to proposed RODC > run dcpromo /UseExistingAccount:Attach > follow wizard or

dcpromo.exe /UseExistingAccount:Attach /unattend:C:\Users\Administrator\Desktop\[unattendStage2].txt

Create install AD snapshot: open command prompt > ntdsutil > activate instance ntds > ifm > create [full|sysvol full|rodc|sysvol rodc] c:\[directory]

Install from media: Copy content of snapshot > dcpromo /adv > follow wizard

References

Steps for deploying an RODC

Configure Active Directory Federation Services (AD FS)

AD FS allows partner companies to configure collaboration resources using existing account partner credentials.

AD FS uses HTTPS between the client and AD FS enabled web servers to secure communications; certificates should be issued from a third party either directly or by implementing AD CS that uses a third party CA as its root.

AD FS uses claims, cookies and certificates to authenticate and authorise users.

AD FS has an account store which contains AD FS tokens of AD DS object attributes.

Claims

A claim is an attribute assigned to a user within Active Directory. The claim can be based on username (identity), group membership (group) or a custom attribute (custom) e.g. partner account number; claims are sent from the account partner to the resource partner encapsulated in security tokens encrypted by a certificate. AD FS has token replay detection functionality which will discard multiple token requests, this is to prevent a cached browser page being submitted by someone else by using the browsers history.

Claims are processed using claim rules; claim rules may represent business logic which processes incoming claims and produces one or more outgoing claims.

Cookies

When a user has successfully authenticated a user is sent an authentication cookie, this cookie is signed but not encrypted therefore the mandatory SSL encryption between client and AD FS enabled web server.

The account partner cookie contains the partner membership information so that partner discovery does not need to take place every time a user authenticates; this cookie is persistent but not signed or encrypted.

The last cookie is the sign-out cookie which cleans up after a user session has ended; the sign-out cookie is a session cookie.

Certificates

Server authentication certificate – this certificate is used to secure communication between web clients and the AD FS enabled web server and AD FS server and AD FS proxies.

Client authentication certificate – this certificate is used by AD FS proxies to authenticate with the AD FS server.

Token-signing certificate – this certificate is used by AD FS servers to digitally sign all security tokens. The public key of the token-signing certificate should be exported as x.509 cer file, if you need the private and public key (when adding a new AD FS server to the farm) then export the certificate keys to a .pfx file.

Verification certificates – this certificate is the token-signing certificate of the sending AD FS server installed on the receiving server. This certificate just contains the public key therefore verifies the security token has not been tampered with in transit.

Trusts

Relying trusts are created by the account partner to present their trust relationship to the resource partner.

Claims provider trusts are created by the resource partner; one is created per account partner.

Role services

Federation servers – authenticates request from clients and sends to resource federation servers; the resource federation server inspects the claim and passes a security token with applicable authorisation to the AD FS enabled web servers web agent.

Federation proxies – deployed within the DMZ to forward requests to the federation server.

AD FS enabled web servers – manage security tokens and authentication cookies

AD FS designs

Federated web (SSO) Single Sign-On

Allows account partner clients to access resource partner resources; will more than likely have AD FS proxies deployed in the DMZ.

Web SSO

In this scenario all users are classed as external; the AD FS proxies and web servers are multi-homed i.e. one connection in the DMZ and one in the internal network. In this scenario the federation server is a resource federation server.

Federated web SSL with forest trust

Allows internal domain users to access applications when located within the intranet or external on the internet. External users can only access applications from the internet. This scenario should also probably use AD LDS rather AD DS in the DMZ as Microsoft do not recommend AD DS in the DMZ.

The AD LDS or AD DS instance within the DMZ will have a one-way forest trust configured with AD DS located in the corporate network. The federation server within the DMZ will be the resource federation server, the account federation server will live in the corporate network.

AD FS authentication

 

 

  1. User attempts to logon to claims aware application
  2.  AD FS enabled web server web agent contacts the AD FS server via the AD FS proxy
  3. The resource partner AD FS server accesses the account partner AD FS server via the AD FS proxies to identify the users access rights
  4. The account partner AD FS server queries AD DS for the users attributes
  5. The account partner AD FS server generates a AD FS security token and sends it to the resource partner AD FS server.
  6. The resource partner AD FS server inspects claims within the security token and generates a signed security token which is passed to the AD FS enabled web servers web agent via the AD FS proxy.
  7. The web agent decrypts the security token and grants access to the web application as defined in the security token. The AD FS enabled web server sends the client user a authentication cookie and account partner cookie.

Notable gotchas

Kerberos tickets cannot tolerate time differences greater than 5 minutes, so make sure the forest uses an reputable time source.

AD FS can only be installed on Enterprise and Datacenter editions.

Cross-DNS referencing required i.e. configure a DNS forwarder; this would be a conditional forwarder that resolves only DNS queries for that particular domain name.

References

Understanding AD FS role services

Understanding federation designs

Understanding claims

Understanding cookies

Understanding certificates used by AD FS

What’s new in Windows Server 2008 R2

Granular password policies which allow multiple password policies per domain.

Restartable Active Directory Directory Services; this allow offline maintenance to be undertaken whilst still processing logon requests.

Tombstone reanimation; basically the AD recycle bin which allows objects to be restored along with their link-valued and non-link-valued attributes.

Best practice analyser for Active Directory.

PowerShell data-driven and task-oriented navigation i.e. Active Directory Administrative Center.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s