What are the new features in Windows 2012 Active Directory

All the new features of Windows 2012 Active Directory are given below.

You can use Active Directory Domain Services (AD DS) in Windows Server 2012 to more rapidly and easily deploy domain controllers (on-premises and in the cloud), increase flexibility when auditing and authorizing access to files, and more easily perform administrative tasks at scale (locally or remotely) through consistent graphical and scripted management experiences. AD DS improvements in Windows Server 2012 include:

• Virtualization that just works

Providing greater support for the capabilities of public and private clouds through virtualization-safe technologies and the rapid deployment of virtual domain controllers through cloning.

• Simplified deployment

Simplifying the on-premises AD DS deployment (formerly DCpromo) with a new streamlined domain controller promotion wizard that is integrated with Server Manager and built on Windows PowerShell.

• Simplified management

Integrating claims-based authorization decisions into AD DS and the Windows platform that permit a combination of centralized access policies, directory attributes, the Windows file-classification engine, and compound-identities comprising both user and machine identity

Providing a consistent graphical and scripted management experience that allows you to perform tasks in the Active Directory Administrative Center that automatically generate the syntax that is required to enable automation for the task in Windows PowerShell.

• AD DS Platform Changes

Updating the AD DS platform with changes such as relative ID improvements, deferred index creation, and off-premises domain join improvements.

Active Directory and AD DS has been at the center of IT infrastructure for over 10 years, and its features, adoption, and business-value have grown release over release. Today, the majority of that Active Directory infrastructure remains on the premises, but there is an emerging trend toward cloud computing.

The adoption of cloud computing, however, will not occur overnight, and migrating suitable on-premises workloads or applications is an incremental and long-term exercise. New hybrid infrastructures will emerge, and it is essential that AD DS support the needs of these new and unique deployment models that include services hosted entirely in the cloud, services that comprise cloud and on-premises components, and services that remain exclusively on the premises. These hybrid models will increase the importance, visibility, and emphasis around security and compliance, and they will compound the already complex and time-consuming exercise of ensuring that access to corporate data and services is appropriately audited and accurately expresses the business intent.

The following sections describe how Windows Server 2012 addresses these emerging needs.

Virtualization that just works

Rapid deployment with cloning

AD DS in Windows Server 2012 allows you to deploy replica virtual domain controllers by “cloning” existing virtual domain controllers. You can promote a single virtual domain controller by using the domain controller promotion interface in Server Manager, and then rapidly deploy additional virtual domain controllers within the same domain, through cloning.

The process of cloning involves creating a copy of an existing virtual domain controller, authorizing the source domain controller to be cloned in AD DS, and running Windows PowerShell cmdlets to create a configuration file that contains detailed promotion instructions (name, IP address, Domain Name System [DNS] servers, and so on). Or you can leave the configuration file empty, which allows the system to automatically fill in the information. Cloning reduces the number of steps and time involved by eliminating repetitive deployment tasks, and it enables you to fully deploy additional domain controllers that are authorized and configured for cloning by the Active Directory domain administrator.


For detailed information about virtualized domain controller cloning see, Active Directory Domain Services (AD DS) Virtualization.

Safer virtualization of domain controllers

AD DS has been virtualized for several years, but features present in most hypervisors can invalidate strong assumptions made by the Active Directory replication algorithms. Primarily, the logical clocks that are used by domain controllers to determine relative levels of convergence only go forward in time. In Windows Server 2012, a virtual domain controller uses a unique identifier that is exposed by the hypervisor. This is called the virtual machine GenerationID. The virtual machine GenerationID changes whenever the virtual machine experiences an event that affects its position in time. The virtual machine GenerationID is exposed to the virtual machine’s address space within its BIOS, and it is made available to the operating system and applications through a driver in Windows Server 2012.

During boot and before completing any transaction, a virtual domain controller running Windows Server 2012 compares the current value of the virtual machine GenerationID against the value that it stored in the directory. A mismatch is interpreted as a “rollback” event, and the domain controller employs AD DS safeguards that are new in Windows Server 2012. These safeguards allow the virtual domain controller to converge with other domain controllers, and they prevent the virtual domain controller from creating duplicate security principals. For Windows Server 2012 virtual domain controllers to gain this extra level of protection, the virtual domain controller must be hosted on a virtual machine GenerationID–aware hypervisor such as Windows Server 2012 with the HyperV role.

For detailed information about the virtualization-safe technology feature see, Active Directory Domain Services (AD DS) Virtualization.

Simplified deployment

AD DS deployment in Windows Server 2012 integrates all the required steps to deploy new domain controllers into a single graphical interface. It requires only one enterprise-level credential, and it can prepare the forest or domain by remotely targeting the appropriate operations master roles. The new deployment process conducts extensive prerequisite validation tests that minimize the opportunity for errors that might have otherwise blocked or slowed the installation. The AD DS installation process is built on Windows PowerShell, integrated with Server Manager, able to target multiple servers, and remotely deploy domain controllers, which results in a deployment experience that is simpler, more consistent, and less time consuming. The following figure shows the AD DS Configuration Wizard in Windows Server 2012.


An AD DS installation includes the following features:

• Adprep.exe integration into the AD DS installation process. Reduces the time required to install AD DS and reduces the chances for errors that might block domain controller promotion.


• The AD DS server role installation, which is built on Windows PowerShell and can be run remotely on multiple servers. Reduces the likelihood of administrative errors and the overall time that is required for installation, especially when you are deploying multiple domain controllers across global regions and domains.

• Prerequisite validation in the AD DS Configuration Wizard. Identifies potential errors before the installation begins. You can correct error conditions before they occur without the concerns that result from a partially complete upgrade.

• Configuration pages grouped in a sequence that mirror the requirements of the most common promotion options, with related options grouped in fewer wizard pages. Provides better context for making installation choices and reduces the number of steps and time that are required to complete the domain controller installation.

• A wizard that exports a Windows PowerShell script that contains all the options that were specified during the graphical installation. Simplifies the process by automating subsequent AD DS installations through automatically generated Windows PowerShell scripts.

For detailed information about AD DS integration with Server Manager see the AD DS deployment guide.

Simplified management

• Dynamic Access Control
• AD DS Claims in AD FS
• Active Directory Federation Services (AD FS)
• Windows PowerShell History Viewer
• Recycle Bin User Interface
• Fine-Grained Password Policy User Interface
• Active Directory Replication and Topology Windows PowerShell cmdlets
• Active Directory Based Activation (AD BA)
• Kerberos Enhancements
• Group Managed Service Accounts (gMSA)



Dynamic Access Control

Background
• Today, it’s difficult to translate business-intent using existing authorization model
• No central administration capabilities
• Existing expression language makes it hard or impossible to fully express requirements
• Increasing regulatory and business requirements around compliance mandate a solution

Solution
• New claims-based authorization platform enhances, not replaces, existing model
    o User-claims and device-claims
    o User+device claims = compound identity
• New central access policies (CAP) model
• Use of file-classification information in authorization decisions
• Easier Access-Denied remediation experience
• Access- and audit-policies can be defined flexibly and simply:
     o IF resource.Confidentiality = high THEN audit.Success WHEN user.EmployeeType = vendor

Requirements
• One or more Windows Server 2012 domain controllers
• Windows Server 2012 file server
• Enable the claims-policy in the Default Domain Controllers Policy
• Windows Server 2012 Active Directory Administrative Center
• For device-claims, compound ID must be switched on at the target service account
       o Via Group Policy or editing the object directly

For more information about Dynamic Access Control see the Dynamic Access Control section of the technical library.

AD DS Claims in AD FS

Background

• AD FS v2.0 is able to generate user-claims directly from NTtokens
• Also capable of further expanding claims based on attributes in AD DS and other attribute stores
• In Windows Server 2012, Kerberos tickets can be populated with user and device attributes serving as claims
     o AD FS 2.0 cannot read claims from Kerberos tickets
     o Must make a separate LDAP call to Active Directory to source user-attribute claims
     o Cannot leverage device-attribute claims at all

Solution
• AD FS (v2.1) in Windows Server 2012 now able to populate SAML tokens with user- and device-claims taken directly from the Kerberos ticket

Requirements

• Dynamic Access Control enabled and configured
• Compound ID must be switched on for the AD FS service account
• Windows Server 2012AD FS (v2.1)

For detailed information about AD FS in Windows Server 2012 see the AD FS section of the technical library.




Active Directory Federation Services (AD FS)

Background
• AD FS v2.0 shipped out-of-band of the Windows Server release

Solution
• In Windows Server 2012, AD FS (v2.1) ships in-the-box as a server role
• Provides:
     o Simplified trust-setup and automatic trust management
     o SAML-protocol support
     o Extensible attribute store
     o Allows claims to be sourced from anywhere in the enterprise
     o Active Directory Lightweight Directory Service (AD LDS) and SQL attribute-store providers supplied out-of-the-box

Requirements
• Windows Server 2012

For detailed information about AD FS in Windows Server 2012 see the AD FS section of the technical library.

Windows PowerShell History Viewer

Background
• Windows PowerShell is a key technology in creating a consistent experience between the command-line and the graphical user interface
• Windows PowerShell increases productivity
    o Requires investment in learning how to use it

Solution
• Allow administrators to view the Windows PowerShell commands executed when using the Active Directory Administrative Center, for example:
     o The administrator adds a user to a group
     o The UI displays the equivalent Windows PowerShell for Active Directory command
     o Administrator copies the resulting syntax and integrates it into their scripts
     o Reduces Windows PowerShell learning-curve
     o Increases confidence in scripting
     o Further enhances Windows PowerShell discoverability

Requirements
• Windows Server 2012 Active Directory Administrative Center

For more information about the Windows PowerShell History Viewer see, Active Directory Administrative Center Enhancements.


Recycle Bin User Interface

Background
• The Recycle Bin feature introduced with Windows Server® 2008 R2 provided an architecture permitting complete object recovery
• Scenarios requiring object recovery via the Recycle Bin are typically high-priority
     o Recovery from accidental deletions, for example, resulting in failed logons/work-stoppages
• The absence of a rich, graphical interface complicated its usage and slowed recovery

Solution
• Simplify object recovery through the inclusion of a Deleted Objects node in the Active Directory Administrative Center (ADAC)
     o Deleted objects can now be recovered within the graphical user interface
• Reduces recovery-time by providing a discoverable, consistent view of deleted object

Requirements
• Recycle Bin requirements must be met:
     o Windows Server 2008 R2 forest functional level
     o Recycle Bin optional-feature must be switched on
• Windows Server 2012 Active Directory Administrative Center
• Objects requiring recovery must have been deleted within Deleted Object Lifetime (DOL)
     o Defaults to 180 days

For more information about the user interface for AD DS Recycle Bin see, Active Directory Administrative Center Enhancements.

Fine-Grained Password Policy User Interface

Background
• The Fine-Grained Password Policy capability introduced with Windows Server 2008 provided more granular management of password-policies
• In order to leverage the feature, administrators had to manually create password-settings objects (PSOs)
     o It proved difficult to ensure that the manually defined policy-values behaved as desired
     o Resulted in time-consuming, trial and error administration

Solution

• Creating, editing and assigning PSOs now managed through the Active Directory Administrative Center
• Greatly simplifies management of password-settings objects

Requirements

• FGPP requirements must be met:
     o Windows Server® 2008 domain functional level
• Windows Server 2012 Active Directory Administrative Center

For more information about the user interface for fine-grained password policies see, Active Directory Administrative Center Enhancements.

Active Directory Replication and Topology Windows PowerShell cmdlets

Background
• Administrators require a variety of tools to manage Active Directory’s site topology
     o repadmin
     o ntdsutil
     o Active Directory Sites and Services
• Results in an inconsistent experience
• Difficult to automate

Solution
• Manage replication and site-topology with Windows PowerShell
     o Create and manage sites, site-links, site-link bridges, subnets and connections
     o Replicate objects between domain controllers
     o View replication metadata on object attributes
     o View replication failures
• Provides a consistent and easily scriptable experience
• Compatible and interoperable with other Windows PowerShell cmdlets

Requirements
• Active Directory Web Service (alson known as Active Directory Management Gateway for Windows server 2003 or Windows Server 2008
• Windows Server 2012 domain controller or Windows Server 2012 with the Role Administration Tools (RSAT) for AD DS and AD LDS installed

For more information about the Windows PowerShell cmdlets to manage Active Directory topology and replication see, Active Directory Replication and Topology Management Using Windows PowerShell.

Active Directory Based Activation (AD BA)

Background
• Today, Volume Licensing for Windows/Office requires Key Management Service (KMS) servers
• Requires minimal training
     o Turnkey solution covers ~90% of deployments
     o Complexity caused by lack of a graphical administration console
• Requires RPC traffic on the network which complicates matters
• Does not support any kind of authentication, the EULA prohibits the customer from connecting the KMS server to any external network
     o For example connectivity-alone to the service equates to activated

Solution
• Use your existing Active Directory infrastructure to activate your clients
     o No additional machines required
     o No RPC requirement, uses LDAP exclusively
     o Includes RODCs
• Beyond installation and service-specific requirements, no data written back to the directory
     o Activating initial CSVLK (customer-specific volume license key) requires:

 One-time contact with Microsoft Activation Services over the Internet (identical to retail activation)
 Key entered using volume activation server role or using command line.
 Repeat the activation process for additional forests up to 6 times by default

• Activation-object maintained in configuration partition
     o Represents proof of purchase
     o Computers can be member of any domain in the forest
• All Windows 8 computers will automatically activate

Requirements

• Only Windows 8 computers can leverage AD BA
• KMS and AD BA can coexist
     o You still need KMS if you require down-level volume-licensing
• Requires Windows Server 2012 Active Directory schema, not Windows Server 2012 domain controllers

For more information about AD BA see the following:
• Volume Activation Services Overview
• Test Lab Guide: Demonstrate Volume Activation Services

Kerberos Enhancements

• Kerberos Constrained Delegation across domains
• Flexible Authentication Secure Tunneling (FAST)

Kerberos Constrained Delegation across domains

Background
• Kerberos Constrained Delegation (KCD) was introduced with Windows Server 2003
• KCD permits a service’s account (front-end) to act on the behalf of users in multi-tier applications for a limited set of back-end services, for example:
     1. User accesses web site as user1
     2. User requests information from web site (front-end) that requires the web server to query a SQL database (back-end)
     3. Access to this data is authorized according to who accessed the front-end
     4. In this case, the web service must impersonate user1 when making the request to SQL

• Front-end configured with the services (by SPN) to which it can impersonate users
• Setup/administration requires Domain Admin privileges
• KCD delegation only works for back-end services in the same domain as the front-end service-accounts

Solution
• KCD in Windows Server 2012 moves the authorization decision to the resource-owners
     o Permits back-end to authorize which front-end service-accounts can impersonate users against their resources
• Supports cross-domain, cross-forest scenarios
• No longer requires Domain Admin privileges
     o Requires only administrative permission to the back-end service-account

Requirements
• Clients run Windows XP or later
• Client domain’s domain controllers running Windows Server 2003 or later
• Front-end server running Windows Server 2012
• One or more domain controllers in front-end domain running Windows Server 2012
• One or more domain controllers in back-end domain running Windows Server 2012
• Back-end server account configured with the accounts that are permitted for impersonation
     o Not exposed through Active Directory Administrative Center
     o Configured through Windows PowerShell:
 New/Set-ADComputer [-name] [-PrincipalsAllowedToDelegateToAccount ]
 New/Set-ADServiceAccount [-name] [-PrincipalsAllowedToDelegateToAccount ]
• Windows Server 2012 schema update in back-end server’s forest
• Back-end application server running Windows Server 2003 or later
For more information about Kerberos constrained delegation see the Kerberos section of the technical library.

Flexible Authentication Secure Tunneling (FAST)

Background
• Offline dictionary attack against password-based logons possible
• Relatively well-known concern around Kerberos errors being spoofed
• Clients may:
     o Fallback to less-secure legacy protocols
     o Weaken their cryptographic key strength and/or ciphers

Solution
• Kerberos in Windows Server 2012 supports Flexible Authentication Secure Tunneling (FAST
     o Defined by RFC 6113
     o Sometimes referred to as Kerberos armoring
• Provides a protected channel between a domain-joined client and DC
     o Protects pre-authentication data for user’s AS_REQs
 Uses LSK (logon session key) from computer’s TGT as shared secret
 Note that computer authentication is NOT armored
     o Allows DCs to return authenticated Kerberos errors thereby protecting them from spoofing
• Once all Kerberos clients and DCs support FAST (the admin’s decision to make)
     o The domain can be configured to either require Kerberos armoring or use it upon request
 Must first ensure all or enough DCs are running Windows Server 2012
 Enable the appropriate policy
 “Support CBAC and Kerberos armoring”
 All DCs can support CBAC and Require Kerberos armoring”
Requirements

• Windows Server 2012 servers
• Ensure that all domains the client uses including transited referral domains:
     o Enable the “Support CBAC and Kerberos armoring” policy for all Windows Server 2012 DCs
     o Have a sufficient number of Windows Server 2012 DCs to support FAST
• Enable “Require FAST” policy on supported clients
• RFC-compliant FAST interoperability requires Windows Server 2012domain functional level

Group Managed Service Accounts (gMSA)

Background
• Managed Service Accounts (MSAs) introduced with Windows Server 2008 R2
• Clustered or load-balanced services that needed to share a single security-principal were unsupported
     o MSAs not able to be used in many desirable scenarios


Solution
• Introduce new security principal type known as a gMSA
• Services running on multiple hosts can run under the same gMSA account
• One or more Windows Server 2012 domain controllers required
     o gMSAs can authenticate against any OS-version DC
     o Passwords computed by Group Key Distribution Service (GKDS) running on all Windows Server 2012 domain controllers
• Windows Server 2012 hosts using gMSAs obtain password and password-updates from GKDS
     o Password retrieval limited to authorized computers
• Password-change interval defined at gMSA account creation (30 days by default)
• Like MSAs, gMSAs are supported only by the Windows Service Control Manager (SCM) and IIS application pools
Requirements
• Windows Server 2012 Active Directory schema updated in forests containing gMSAs
• One or more Windows Server 2012 domain controllers to provide password computation and retrieval
• Only services running on Windows Server 2012 can use gMSAs
For more information about group managed service accounts see the Managed Service Accounts section of the technical library.

AD DS Platform Changes

• Relative ID (RID) Improvements
• Deferred Index Creation
• Off-Premises Domain Join

Relative ID (RID) Improvements 
• Periodic RID consumption warning
    o At 10% of remaining global space, system logs informational event
 First event at 100,000,000 RIDs used, second event logged at 10% of remainder
 Remainder = 900,000,000
 10% of remainder = 90,000,000
 Second event logged at 190,000,000
 Existing RID consumption plus 10% of remainder
     o Events become more frequent as the global space is further depleted
• RID Manager artificial ceiling protection mechanism
     o A soft ceiling
     o Blocks further allocations of RID pools
 When the ceiling is reached, system sets msDS-RIDPoolAllocationEnabled attribute of the RID Manager$ object to FALSE. An administrator must set it back to TRUE to override.
     o Log an event indicating that the ceiling is reached
 An additional warning is logged when the global RID spaces reaches 80%
o The attribute can only be set to FALSE by the SYSTEM and is mastered by the RID master (for example, write it against the RID master)
 DA can set it back to TRUE
Note 
It is set to TRUE by default

• The soft ceiling is 90% of the global RID space and is not configurable
• The soft ceiling is deemed as ”reached” when a RID pool containing the 90% RID is issued
Requirements 
• Windows Server 2012 RID master
• Windows Server 2012 Domain Controllers
For more information on RID improvements see, Understand and Troubleshoot AD DS Simplified Administration in Windows Server "8" Beta.

Deferred Index Creation

• Windows Server 2012 introduces new DSheuristic
     o 18th byte but uses a zero-base, so some say the 19th byte
     o Setting it to 1 causes any Windows Server 2012 DC to defer building indices until:
 It receives the UpdateSchemaNow rootDSE mod. (triggers rebuild of the schema cache)
 It is rebooted (which requires that the schema cache be rebuilt and, in turn, the deferred indices)
• Any attribute that is in a deferred index state will be logged in the Event Log every 24 hours
     o 2944: Index deferred – logged once
     o 2945: Index still pending – logged every 24 hours
     o 1137: Index created – logged once (not a new event)
Requirements 

• Windows Server 2012 Domain Controllers

Off-Premises Domain Join 

• Extends offline domain-join by allowing the blob to accommodate Direct Access prerequisites
     o Certs
     o Group Policies
• What does this mean?
     o A computer can now be domain-joined over the Internet if the domain is Direct Access enabled
     o Getting the blob to the non-domain-joined machine is an offline process and the responsibility of the administrator
Requirements
• Windows Server 2012 Domain Controllers

Here is a Demo on Top Ten Features of Windows 2012.

Windows Server 2012 New Features.

Windows server 2012 File and Storage Management

How to Install Active Directory in Windows 2012

Read More

What are advance audit policy settings?

In Windows 7 and Windows Server 2008 R2, the number of audit settings for which success and failure can be tracked has increased to 53. Previously, there were nine basic auditing settings under Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Audit Policy. These 53 new settings allow you to select only the behaviors that you want to monitor and exclude audit results for behaviors that are of little or no concern to you, or behaviors that create an excessive number of log entries. In addition, because Windows 7 and Windows Server 2008 R2 security audit policy can be applied by using domain Group Policy, audit policy settings can be modified, tested, and deployed to selected users and groups with relative simplicity.

Please read this article for more details

Read More

Can you roll back Forest functional level of Windows 2008 R2?

After you set the forest functional level to a certain value in Windows Server 2008 R2, you cannot roll back or lower the forest functional level, with one exception: when you raise the forest functional level to Windows Server 2008 R2 and if the Active Directory Recycle Bin is not enabled, you have the option of rolling the forest functional level back to Windows Server 2008. For more information about the Active Directory Recycle Bin, see What's New in AD DS: Active Directory Recycle Bin (http://go.microsoft.com/fwlink/?LinkId=141392). You can lower the forest functional level only from Windows Server 2008 R2 to Windows Server 2008. If the forest functional level is set to Windows Server 2008 R2, it cannot be rolled back to Windows Server 2003, for example.

For more details on forest Functional Level Please read this article.

Read More

What are Group Policy preferences in Windows 2008?

Group Policy preferences that are new in Windows Server 2008 and how to enable down-level computers to process these new items. Group Policy preferences are made up of more than 20 new Group Policy client-side extensions (CSEs) that expand the range of configurable settings in a Group Policy object (GPO). These new preference extensions are included in the Group Policy Management Editor window of the Group Policy Management Console (GPMC). The kinds of preference items that can be created by using each extension are listed when New is selected for the extension. Examples of the new Group Policy preference extensions include the following:

• Folder Options
• Drive Maps
• Printers
• Scheduled Tasks
• Services
• Start Menu

For more details please read this KB Article.

Download the Microsoft Doc file from here.

Read More

Explain Managed Service Accounts in Active Directory.

A new feature to manage service accounts in Windows 7 and Windows Server 2008 R2 to help you maintain and secure your IT environment.

Managed service accounts in Windows Server 2008 R2

Background
One of the security challenges for critical network applications is selecting the appropriate type of account for the application to run as:

• On a local computer, an administrator can configure the application to run as Local Service, Network Service, or Local System. These service accounts are simple to configure and use, but they are typically shared among multiple applications and services and cannot be managed on a domain level.
• If you configure the application to use a domain account, you can isolate the privileges for the application. However, you need to manually manage passwords or create a custom solution for managing these passwords.

Overview of the managed service account
The managed service account is designed to provide applications such as SQL Server or Exchange with:

• Automatic password management, which can better isolate these services from other services on the computer.
  
  

  Important

  The default password refresh behavior for the managed service account is to be automatically updated every 30 days. However, this can cause a failed authentication attempt because the NTLM and Kerberos security support providers will not recognize the new password. To rectify this problem permanently, install the hot fix as described in the knowledge base article “Managed service account authentication fails after its password is changed in Windows 7 or in Windows Server 2008 R2 (KB 2494158).”

• Simplified service principal name (SPN) management, which allows service administrators to set SPNs on these accounts. In addition, SPN management can be delegated to other administrators.

Management
To configure and manage these accounts for a service running on Windows 7 or Windows Server 2008 R2, you will need to use Windows PowerShell cmdlets. There is no UI support for creating and managing these accounts.
Service accounts are also supported on Windows Server 2003 and Windows Server 2008 domain controllers. For information about these requirements and additional configuration steps, see Managed Service Accounts Step-by-Step Guide.

Resources for managed service accounts

For information about how to set up managed service accounts, see Managed Service Accounts Step-by-Step Guide.

Read More

What is NTLM Blocker in Active Directory in Windows 2008?

Q. What is NTLM Blocker in Windows 2008 R2 and Windows 7?
Q. How does it work?
Q. Can we have any kind of exclusion?



New Group Policy settings in Windows 7 and Windows Server 2008 R2 permit the restriction of NTLM protocol usage on clients, servers, and domain controllers. These policies can be configured on computers running Windows 7 and Windows Server 2008 R2, which can affect NTLM usage on computers running earlier versions of Windows.
The following Security Option settings can be configured to help you restrict NTLM usage in your environment.

• Network Security: Restrict NTLM: Incoming NTLM Traffic
• Network Security: Restrict NTLM: NTLM authentication in this domain
• Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers

To know more click here

Read More