What is anonymous authentication and what are the risks involved in enabling it?

Enabling anonymous authentication for earlier applications
Anonymous authentication allows users and network clients to be authenticated (but not necessarily authorized to access network resources) without providing any credentials. Unlike earlier Windows operating systems, in Windows Server 2003, anonymous users are not considered to be members of the Everyone group and therefore will not be authorized to use any network resources. However, there are some scenarios in which anonymous access needs to be granted to provide compatibility with systems prior to Windows 2000. Situations in which this access might be necessary include:
· Remote Access Server (RAS) servers on Windows NT 4.0 use anonymous access to determine dial-in permissions.
· Windows NT 4.0 might use anonymous access to enumerate shares or gather information from domain controllers.
· Anonymous access might be used to enumerate shares and users in a one-way cross-forest trust.
· Earlier operating systems might use anonymous access to change passwords in Active Directory. This is accomplished through the Pre–Windows 2000–compatible access group.
If you have earlier systems in your Windows Server 2003 domain, you will need to determine which resources need anonymous access. You can then enable anonymous access by performing one of the following tasks:
· Add the Anonymous Logon security principal to the ACL that needs access. This is the preferred method for enabling anonymous access to resources because it is the most granular.
· Enable the Network Access: Share That Can Be Accessed Anonymously security policy setting. This security policy setting contains a list of shares that can be accessed and is useful for enabling anonymous access to a specific share on multiple computers.
· Enable the Network Access: Let Everyone Permissions Apply To Anonymous Users security policy setting. This setting causes unauthenticated users to be considered members of the Everyone group, which might authorize users to access network resources without being authenticated as valid users. This setting should only be enabled when absolutely necessary, because it creates a significant, exploitable vulnerability.
Caution
Apply the Anonymous Logon, Network Access: Share That Can Be Accessed Anonymously, Network Access: Let Everyone Permissions Apply To Anonymous Users settings only to the OU or server that needs them. Enabling these settings at the domain level will decrease network security.

Read More

What are different group policies related to kerberos tickets?

The following table describes the default domain policy options available for Kerberos tickets. These policy settings are located in the Kerberos Policy node in Account Policies.
Security Policy Settings for Kerberos Ticket Policy
Security policy setting
Description
Enforce user logon restrictions
Determines whether the KDC validates every request for a session ticket by examining the user rights policy on the target computer. This option also serves as a means of ensuring that the requesting account is still valid and was not disabled since the Kerberos ticket was issued. This option could potentially slow down network logons.
Maximum lifetime for service ticket
Determines the amount of time a service ticket is available before it expires. This setting should be set the same as the user ticket setting, unless your users run jobs that are longer then their user tickets would allow.
Maximum lifetime for user ticket
Determines the amount of time a user ticket is available before it expires. This setting should be set according to the average amount of time a user logs on to a computer at your organization.
Maximum lifetime for user ticket renewal
Determines the number of days for which a user's TGT can be renewed. The default is seven days. Shortening this interval will increase security but put more load on the KDC.
Maximum tolerance for computer clock synchronization
Determines the maximum time difference (in minutes) between the time on the user's computer's clock and the time on the domain controller. Raising this value from the default of five minutes increases your vulnerability to replay attacks, in which encrypted credentials captured from the network are resubmitted by a malicious attacker. Lowering this value will increase the number of authentication failures caused by unsynchronized clocks.

Read More

How Kerberos authentication works?

The Kerberos Authentication Process
The Kerberos protocol gets its name from the three-headed dog in Greek mythology. The three components of Kerberos are:
· The client requesting services or authentication.
· The server hosting the services requested by the client.
· A computer that is trusted by the client and server (in this case, a Windows Server 2003 domain controller running the Kerberos Key Distribution Center service).
Kerberos authentication is based on specially formatted data packets known as tickets. In Kerberos, these tickets pass through the network instead of passwords. Transmitting tickets instead of passwords makes the authentication process more resistant to attackers who can intercept the network traffic.
Key Distribution Center
The Key Distribution Center (KDC) maintains a database of account information for all security principals in the domain. The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long term key. The long term key is derived from a user's logon password.
Kerberos authentication process
In a Kerberos environment, the authentication process begins at logon. The following steps describe the Kerberos authentication process:
1. When a user enters a user name and password, the computer sends the user name to the KDC. The KDC contains a master database of unique long term keys for every principal in its realm.
2. The KDC looks up the user's master key (KA), which is based on the user's password. The KDC then creates two items: a session key (SA) to share with the user and a Ticket-Granting Ticket (TGT). The TGT includes a second copy of the SA, the user name, and an expiration time. The KDC encrypts this ticket by using its own master key (KKDC), which only the KDC knows.
Note:
Kerberos implements secret key cryptography, which is different from public key cryptography in that it does not use a public and private key pair.
3. The client computer receives the information from the KDC and runs the user's password through a one-way hashing function, which converts the password into the user's KA. The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.
Important:

When a client receives the session key and TGT from the server, it stores that information in volatile memory and not on the hard disk. Storing the information in the volatile memory and not on the hard disk makes the information more secure, because the information would be lost if the server were physically removed.
4. When a Kerberos client needs to access resources on a server that is a member of the same domain, it contacts the KDC. The client will present its TGT and a timestamp encrypted with the session key that is already shared with the KDC. The KDC decrypts the TGT using its KKDC. The TGT contains the user name and a copy of the SA. The KDC uses the SA to decrypt the timestamp. The KDC can confirm that this request actually comes from the user because only the user can use the SA.
5. Next, the KDC creates a pair of tickets, one for the client and one for the server on which the client needs to access resources. Each ticket contains the name of the user requesting the service, the recipient of the request, a timestamp that declares when the ticket was created, and a time duration that says how long the tickets are valid. Both tickets also contain a new key (KAB) that will be shared between the client and the server so they can securely communicate.
6. The KDC takes the server's ticket and encrypts it using the server master key (KB). Then the KDC nests the server's ticket inside the client's ticket, which also contains the KAB. The KDC encrypts the whole thing using the session key that it shares with the user from the logon process. The KDC then sends all the information to the user.
7. When the user receives the ticket, the user decrypts it using the SA. This exposes the KAB to the client and also exposes the server's ticket. The user cannot read the server's ticket. The user will encrypt the timestamp by using the KAB and send the timestamp and the server's ticket to the server on which the client wants to access resources. When it receives these two items, the server first decrypts its own ticket by using its KB. This permits access to the KAB, which can then decrypt the timestamp from the client.

Read More

Please explain us the NTLM Authentication process?

NTLM Authentication Process
NTLM includes three methods of challenge-response authentication: LM, NTLMv1, and NTLMv2. The authentication process for all the methods is the same, but they differ in the level of encryption.
The following steps demonstrate the flow of events that occur when a client authenticates to a domain controller using any of the NTLM protocols:
1. The client and server negotiate an authentication protocol. This is accomplished through the Microsoft negotiate Security Support Provider (SSP).
2. The client sends the user name and domain name to the domain controller.
3. The domain controller generates a 16-byte random character string called a nonce.
4. The client encrypts the nonce with a hash of the user password and sends it back to the domain controller.
5. The domain controller retrieves the hash of the user password from the security account database.
6. The domain controller uses the hash value retrieved from the security account database to encrypt the nonce. The value is compared with the value received from the client. If the values match, the client is authenticated.

Read More

What are new features introduced in Windows 2008 domain functionality level?

Features enabled at domain functional levels

http://technet2.microsoft.com/windowsserver2008/en/library/34678199-98f1-465f-9156-c600f723b31f1033.mspx?mfr=true

Read More

What are different Authentication Protocols available in Windows Server 2003?

Windows Server 2003 provides the ability to authenticate a variety of client operating systems. Because client operating systems support various levels of authentication protocols, Windows Server 2003 supports two primary authentication protocols: NTLM and Kerberos.
The NTLM authentication protocol uses a challenge-response mechanism to authenticate users and computers running Windows Me and earlier operating systems, or computers running Windows 2000 or later that are not part of a domain. A user is prompted (the challenge) to provide some private piece of information unique to the user (the response). Windows Server 2003 supports the following three methods of challengeresponse authentication:
LAN Manager (LM). Developed jointly by IBM and Microsoft for use in OS2 and Windows for Workgroups, Windows 95, Windows 98, and Windows Me. It is the least secure form of challenge-response authentication because it is susceptible to eavesdropping attacks, and servers that authenticate users with LM authentication must store credentials in an LMHash.
NTLM version 1. A more secure form of challenge-response authentication than LM. It is used for connecting to servers running Windows NT with Service Pack 3 or earlier. NTLMv1 uses 56-bit encryption to secure the protocol. Servers that authenticate users with any version of NTLM authentication must store credentials in an NT Hash.
NTLM version 2. The most secure form of challenge-response authentication available. This version includes a secure channel to protect the authentication process. It is used for connecting to servers running Windows 2000, Windows XP, and Windows NT with Service Pack 4 or higher. NTLMv2 uses 128-bit encryption to secure the protocol.
Kerberos is the default authentication protocol for Windows Server 2003, Windows 2000, and Windows XP Professional. Kerberos is designed to be more secure and scalable than NTLM across large, diverse networks.

Read More

What are the improvements introduced in AD Directory Domain Service Installation wizard?

Active Directory Domain Services Installation Wizard
New Wizard Page Description

Additional options :Specifies that during the domain controller installation, the domain controller will also be configured to be a DNS server, global catalog server or RODC.
Site selection : Specifies the site in which the domain controller should be installed.
Set function levels: Sets the domain and forest functional level during the installation of a new domain or forest.
Password Replication Policy: Specifies which account passwords to allow or deny from being cached on an RODC. This page appears only if the Use advanced mode installation check box is selected.
DNS delegation creation: Provides a default option to create a DNS delegation based on the type of domain controller installation (as specified on the Choose a Deployment Configuration page) and the DNS environment.


The new Active Directory Domain Services Installation Wizard also includes the following improvements:

· By default, the wizard now uses the credentials of the user who is currently logged on. You are prompted for additional credentials if they are needed.
· When you create an additional domain controller in a child domain, the wizard now detects if infrastructure master role is hosted on a global catalog server in that domain, and the wizard prompts you to transfer the infrastructure master role to the domain controller that you are creating if it will not be a global catalog server. This helps prevent misplacement of the infrastructure master role.
· On the Summary page of the wizard, you can export the settings that you have selected to a corresponding answer file that you can use for subsequent operations (installations or uninstallations).
· You can now force the demotion of a domain controller that is started in Directory Services Restore Mode.

Read More

What are the improvements introduced in AD Directory Domain Service Installation wizard?

Active Directory Domain Services Installation Wizard
New Wizard Page Description

Additional options :Specifies that during the domain controller installation, the domain controller will also be configured to be a DNS server, global catalog server or RODC.
Site selection : Specifies the site in which the domain controller should be installed.
Set function levels: Sets the domain and forest functional level during the installation of a new domain or forest.
Password Replication Policy: Specifies which account passwords to allow or deny from being cached on an RODC. This page appears only if the Use advanced mode installation check box is selected.
DNS delegation creation: Provides a default option to create a DNS delegation based on the type of domain controller installation (as specified on the Choose a Deployment Configuration page) and the DNS environment.


The new Active Directory Domain Services Installation Wizard also includes the following improvements:

· By default, the wizard now uses the credentials of the user who is currently logged on. You are prompted for additional credentials if they are needed.
· When you create an additional domain controller in a child domain, the wizard now detects if infrastructure master role is hosted on a global catalog server in that domain, and the wizard prompts you to transfer the infrastructure master role to the domain controller that you are creating if it will not be a global catalog server. This helps prevent misplacement of the infrastructure master role.
· On the Summary page of the wizard, you can export the settings that you have selected to a corresponding answer file that you can use for subsequent operations (installations or uninstallations).
· You can now force the demotion of a domain controller that is started in Directory Services Restore Mode.

Read More

What is Active Directory object quota? How can you set it?

Directory Object Quotas
A denial-of-service attack can be performed by creating a huge number of objects in Active Directory. This could also happen unintentionally because of a bug in an application or a human error. To protect from such incidences, you can set quotas on how many directory objects a given security principal (user, inetOrgPerson, computer) can own in a given partition. (This includes domain and application partitions and the configuration partition, but the schema partition doesn't support quotas.) The object's creator becomes its owner, but as you know, the ownership can be transferred.
Windows 2000 doesn't understand or enforce directory object quotas, so for the quotas to be effective, all domain controllers that host the corresponding partition should be running Windows Server 2003. Also, quotas are enforced only on originating updates and not when a replicated update is applied.

Setting Directory Object Quotas
You can set a default quota for the partition and individual quotas for users, inetOrgPersons, computers, and security groups. If there is a quota for both a user and one or more groups she is a member of, the largest quota is used. If an individual quota is not assigned (either directly or through group membership), the quota of the partition is used. By default, the partition quota is unlimited. Members of Domain Admins and Enterprise Admins are not subject to quota control.
You would use the DS commands to manage quotas. The first of the following commands sets Jack's quota to 15 owned objects in the Sanao domain. The second command raises his quota to 18 objects, and the third command sets the default quota for the partition.
Command 1:
dsadd quota -part DC=sanao,DC=com -acct jack.brown@sanao.com

-qlimit 15
Command 2:
dsmod quota "CN=SANAO_JackB,CN=NTDS Quotas,DC=sanao,DC=com"

-qlimit 18
Command 3:
dsmod partition DC=sanao,DC=com -qdefault 500

Viewing Directory Object Quotas
You can view individual quota entries, effective quota limits, and the current quota usage with DS commands. An effective quota limit sums up the effect if a user is in a group that has a higher quota, and if none of the quota entries apply, the effective limit equals the partition default.
The following command displays the effective quota limit along with the current usage: dsget user "CN=jack brown,OU=boston,DC=sanao,DC=com" -part DC=sanao,DC=com -qlimit -qused

To see the effective quota and the current usage for all users in a domain, use the following command:dsquery user domainroot dsget user -part DC=sanao,DC=com -qlimit -qused -dn

To get a list of all quota entries that are at least ten objects, you can specify a filter in the DSQuery command, pipe the result to DSGet, and specify that you want the name (acct) and quota limit (qlimit) displayed. dsquery quota domainroot -qlimit ">=10" dsget quota –acct -qlimit

The CN=NTDS Quotas object contains two constructed attributes, msDS-QuotaEffective and msDS-QuotaUsed, which display a different result for each user—that is, her own effective quota limit and current usage.
Tombstone Quotas
When an object is deleted, most of its attributes are stripped, and what is left, is called a tombstone. This tombstone exists by default for 60 days, so that knowledge of the deletion can be replicated to all domain controllers (even if one of them were offline for 55 days). It is possible to have the tombstones counted with a lower weight, when the user's quota usage is determined.
By default, the tombstone weight is 100, which means that they are as "expensive" as normal objects. To set the weight to 50 percent, for example, you would use the following command:
dsmod partition DC=sanao,DC=com -qtmbstnwt 50

Read More

How do you Define the Scope of Fine-Grained Password Policies?

A PSO Password Settings objects (PSOs) can be linked to a user (or inetOrgPerson) or group object that is in the same domain as the PSO.
· A PSO has an attribute named PSOAppliesTo that contains a forward link to only user or group objects. The PSOAppliesTo attribute is multivalued, which means that you can apply a PSO to multiple users or groups. You can create one password policy and apply it to different sets of users or groups.
· A new attribute named PSOApplied has been added to the user and group objects in Windows Server 2008. The PSOApplied attribute contains a back-link to the PSO. Because the PSOApplied attribute has a back-link, a user or group can have multiple PSOs applied to it. In this case, the settings that are applied are calculated by Resultant Set of Policy (RSOP). You can link a PSO to other types of groups in addition to global security groups. However, when the resultant set of policy is determined for a user or group, only PSOs that are linked to global security groups or user objects are considered. PSOs that are linked to distribution groups or other types of security groups are ignored.

If multiple PSOs are linked to a user or group, the resultant PSO that is applied is determined as follows:
· A PSO that is linked directly to the user object is the resultant PSO. If more than one PSO is linked directly to the user object, a warning message is logged in the event log and the PSO with the lowest precedence value is the resultant PSO.
· If no PSO is linked to the user object, the global security group memberships of the user, and all PSOs that are applicable to the user based on those global group memberships, are compared. The PSO with the lowest precedence value is the resultant PSO.
· If no PSO is obtained from conditions (1) and (2), the Default Domain Policy is applied.

Read More

What is AdminSDHolder Object and how admincount attribute is associated with it? How can you list all the affected objects?

What is AdminSDHolder Object and how admincount attribute is associated with it? How can you list all the affected objects?


Active Directory contains a mechanism to protect the user accounts and groups that are members of administrative groups. Also, the administrative groups are protected, not just their members. Every hour, the domain controller that holds the PDC master role in the domain checks that the permission lists and inheritance setting of these user accounts and groups are identical to the permission list and inheritance setting of a special AdminSDHolder object. The PDC master modifies any differing permission list, so that it will be again identical to the permission list of AdminSDHolder.
Users and groups that are protected with this mechanism are identified with the adminCount attribute value of 1. The PDC master sets this attribute value during its hourly check for all new users and groups that have become members of protected groups during the last hour. You can list all the affected objects to a file, using a command such as the following:

ldifde -f prot.txt -d DC=sanao,DC=com -r (adminCount=1) -l dn

In AD2000, the protected groups are Enterprise Admins, Schema Admins, Domain Admins, and Administrators. AD2003 extends the list (as does Windows 2000 SP4) by adding Account Operators, Server Operators, Print Operators, Backup Operators, and Replicator. In addition, Administrator, the Domain Controllers group (but not its members), and krbtgt are protected. Consequently, account operators can no longer modify their own accounts or the accounts of other account operators.
If a user is removed from a protected group, the hourly permission check (and the possible restoration) that the PDC master performs stops applying to the user object. The PDC master does not restore the old permission entries that existed perhaps six months earlier, before the user was added to the protected group. You must manually specify any permission or inheritance settings you want after the removal from the group. In addition, the adminCount attribute is probably not cleared automatically, so you might want to do that manually. It does not seem to hurt to still have that attribute value set, but it's better to clear it.

This object and its AD worker code is used by Domain Controllers to protect high-privilege accounts from inadvertent modification – i.e. if an administrator account was moved into an OU that was being maintained by an delegated OU admin, it makes sure the high-privilege permissions are not stripped away. You can probably think of a few reasons why allowing a member of Enterprise Admins to be monkeyed with is a Bad Thing™.

Anyhoo, the way this works is there’s a special object located at:

cn=adminsdholder,cn=system,dc=contoso,dc=com

Any security descriptors for those groups listed on that object are re-stamped on the user object members every 60 minutes. So you may have run into this where you had made some custom ACL changes on your Administrator user that was a member of some OU, then found an hour later that your changes had disappeared. All by design, all well-and-good. There is also the related SDProp code, which computes and fixes up group memberships for Administrative groups. Both tasks operate only on the PDC Emulator.

So here are the questions Microsoft gets asked most commonly about this system, and where we haven’t always done the best job documenting answers – until now. :-)

Question: How does the AdminSdHolder operation determine whether or not to ACL an account?

Answer: It is based on transitively expanding the list of (possibly nested) protected groups. The attribute AdminCount was originally used only as an optimization to improve performance, since it was assumed that regardless of group membership, AdminCount being 1 should trigger protection. However from repro's on Windows Server 2003 and source code review, it appears this is no longer enough to actually trigger the AdminSdHolder operation all on its own.

When a Security Principal is a member of a protected group its Security Descriptor is stamped with the SD of the AdminSDHolder Object for that domain. Also the Security Principal's adminCount attribute is set to value 1. If the SD of the security principal in question already matches the SD of the AdminSDHolder Object, the object is left untouched. Consequently its adminCount value could potentially remain 0. So using AdminCount is a pure mark of whether or not a user is protected is not always a good idea – the group membership is the key.

Question: What is AdminCount, and why is it not being decremented to ‘0’ or ‘’ when I remove a user from a Protected Group?

Answer: AdminCount is an attribute on the user account that is set to 1 on any users being protected by AdminSdHolder. When protected, the user gets this attribute set and the security inheritance bit is removed from their account.

The reason AdminCount isn’t set back to 0 when the user is removed from a protected group is that you told us not to! A survey of customers early on in Windows 2000's design found that they favored deleting a user account after its high-privilege rights were revoked, as the account could have created explicit backdoors before having its rights stripped. Therefore the DC does not remove the AdminCount attribute entry, as it is assumed that the account is going to be disabled or deleted.

If for some reason you didn’t want to get rid of that account after ‘de-admining’ it, you must manually set back to allowing inheritance and set AdminCount to 0, usually through ADSIEDIT.MSC..

Question: Is it possible to make AdminSDHolder code run more or less frequently? What about SDProp?

Answer: Yes, with a big caveat.

To change the frequency of AdminSdHolder in SDPRop, set the following through regedit:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"AdminSDProtectFrequency"=

The value is a DWORD and you can set a range from 60 to 7200 decimal (it's in seconds). By setting it to 60 you would override the default 60 minute wait time and it would fire every minute. By setting to 7200 it would run every 2 hours.

Note that lowering the default is NOT recommended except for lab testing due to the potential LSASS performance ramifications in a large environment. I.e. doing this could cause your DC’s processor to spike to very high sustained levels and drastically hurt you.

You can cause SDProp to run once ‘right now’ by using the steps in KB 251343 to execute FixUpInheritance.

Question: Is there a way to warn administrators that a user being manipulated is covered under AdminSDHolder and SDProp? How do we stop Admins from doing ‘bad’ stuff like this?

Answer: Nope, you just gotta know.

As to how you stop Administrators from doing theoretically ‘bad’ stuff – with great power comes great responsibility; AdminSDHolder can only protect you so far from yourself. This is similar to customers who ask us ‘how do I keep administrators from reading all the files on the network?’ The answer is: you cannot. Trust your administrators, bond your administrators, or get different administrators.

Question: Where are all the best articles on AdminSdHolder and related… stuff?

Answer:

• Description and Update of the Active Directory AdminSDHolder Object - KB 232199.
• Delegated permissions are not available and inheritance is automatically disabled - KB 817433.
• How To Delegate the Unlock Account Right (which is often why you run into this) – KB 294952.
• AdminSdHolder Open Specification Document - 3.1.1.6.1 AdminSDHolder.
• Michael B. Smith has an excellent and very readable article on his blog here.

And that’s that.

Read More

How are Fine grained password Policies are stored in Windows server 2008? What are different objects associated with it?

To store fine-grained password policies, Windows Server 2008 includes two new object classes in the Active Directory Domain Services schema:
· Password Settings Container
· Password Settings

Password Settings Container is created by default under the System container in the domain. It stores the Password Settings objects (PSOs) for that domain. You cannot rename, move or delete this container.

A PSO has attributes for all the settings that can be defined in the Default Domain Policy (except Kerberos settings). These settings include attributes for the following password settings:

· Enforce password history
· Maximum password age
· Minimum password age
· Minimum password length
· Passwords must meet complexity requirements
· Store passwords using reversible encryption

These settings also include attributes for the following account lockout settings:
· Account lockout duration
· Account lockout threshold
· Reset account lockout after

In addition, a PSO has the following two new attributes:
· PSO link. This is a multivalued attribute that is linked to users and/or group objects.
· Precedence. This is an integer value that is used to resolve conflicts if multiple PSOs are applied to a user or group object.
These nine attributes are mustHave attributes. This means that you must define a value for each one. Settings from multiple PSOs cannot be merged.

Read More

What is Well known Security principal?

Well-Known Security Principals
The term well-known security principal refers to fixed accounts that are somewhat like users or groups. However, you cannot delete or rename them. Actually, you don't even see them in the list of users and groups (except in the dialog boxes where you give permissions).
A well-known security principal may include a number of users, but you cannot designate who these "members" are. For example, whether a user is a "member" of Interactive depends on the circumstances—he is a "member" if he is sitting at the computer where the resource being accessed resides.
The reason for well-known security principals to exist is that they allow administrators to assign permissions to these special identities, so that appropriate users can use those permissions. You can also think of well-known security principals as "dynamic groups," because their "member" lists are dynamically determined. Do not confuse them, however, with query-based groups, which were introduced in Windows Server 2003. The number of these "dynamic groups" was increased in Windows Server 2003, compared to Windows 2000 (which in turn was increased, compared to Windows NT). This indicates that future versions of Windows may introduce even more of them, such as "Those-who-authenticated-using-a-smart-card."

List of well known Security Principal.
anonymous Logon; Authenticated Users; Batch; Creator Owner; Creator Group; Dialup; Enterprise Domain Controllers; Everyone; Interactive; Network; Proxy; Restricted; Self (or Principal Self); Service; System (or LocalSystem); Terminal Server User; This Organization; Other Organization; Local Service; Network Service; NTLM Authentication; SChannel Authentication; Digest Authentication; Remote Interactive Logon.
Refer:
http://support.microsoft.com/kb/243330

Read More

What is BitLocker? How does it work?

BitLocker

Windows BitLocker Drive Encryption is a data protection feature available in Windows Vista Enterprise and Windows Vista Ultimate for client computers and in Windows Server 2008. BitLocker provides enhanced protection against data theft or exposure on computers that are lost or stolen, and more secure data deletion when BitLocker-protected computers are decommissioned.

Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software attack tool against it or by transferring the computer’s hard disk to a different computer. BitLocker helps mitigate unauthorized data access on lost or stolen computers by combining two major data-protection procedures:
•
Encrypting the entire Windows operating system volume on the hard disk. BitLocker encrypts all user files and system files in the operating system volume, including the swap and hibernation files.
•
Checking the integrity of early boot components and boot configuration data. On computers that have a Trusted Platform Module (TPM) version 1.2, BitLocker leverages the enhanced security capabilities of the TPM to help ensure that your data is accessible only if the computer’s boot components appear unaltered and the encrypted disk is located in the original computer. If you enable BitLocker on a computer that has a TPM version 1.2, you can add a second factor of authentication to the TPM protection. BitLocker offers the option to lock the normal boot process until the user supplies a personal identification number (PIN) or inserts a USB device (such as a flash drive) that contains a BitLocker startup key. These additional security measures provide multifactor authentication and helps ensure that the computer will not start or resume from hibernation until the correct PIN or startup key is presented.
BitLocker is tightly integrated into Windows Server and provides enterprises with enhanced data protection that is easy to manage and configure. For example, BitLocker can use an existing Microsoft Active Directory Domain Services (AD DS) infrastructure to remotely store BitLocker recovery keys. BitLocker also provides a recovery console that enables data retrieval for non-domain-joined computers or computers that are unable to connect the domain (for example, computers in the field).

Read More

What is access token and how it is used?

Access Tokens
An access token describes the security context of a process. When the process tries to perform various operations in the computer, Windows uses access token information to determine whether to allow or disallow each operation.
Each time a user or background process authenticates itself to some computer (e.g., when a user logs on), Windows NT/2000/XP/Server 2003 in that target computer builds an access token for that user for that session. An access token contains the following:
· SID for the user account
· SIDs for the groups the user is a member of (either directly or via other groups), including any well-known security principals, such as Interactive, the user dynamically "is a member of"
· List of the user rights held by the user or his groups
· Default permissions (default DACL) for newly created objects
· Owner SID—that is, the default owner for newly created objects (it must be one of the user or group SIDs in this access token)
· Primary group SID—that is, the default primary group for newly created objects (it must be one of the group SIDs in this access token)
· Access token source, which is an eight-character string that distinguishes sources such as Session Manager, LAN Manager, and RPC Server
· Indication of whether the access token is a normal ("primary") or impersonation access token
Especially the first three items identify "who" this process is and which rights it has. Each process has a primary access token. When a thread in a serving process impersonates a client, it has another access token called an impersonation token, or sometimes a client access token.
An access token is either built or copied. The access token is built during logon or authentication to a new server. If the user then starts new processes without specifying a different username, the access token of the starting process is copied more or less identically to the new process.
You may know that changes in group memberships are not effective until the user in question logs off and then logs on again. The reason is that the access token with the group information is generated only at logon time or when authenticating to a new server.

Read More

What are Fine-Grained Password Policies in Longhorn server? How does it improve existing password policy available in Windows 2003?

Fine-grained Password Policy

Windows Server 2008 provides organizations with a way to define different password and account lockout policies for different sets of users in a domain. In Windows 2000 and Windows Server 2003 Active Directory domains, only one password policy and account lockout policy could be applied to all users in the domain. These policies were specified in the Default Domain Policy for the domain. As a result, organizations that wanted different password and account lockout settings for different sets of users had to either create a password filter or deploy multiple domains. Both options are costly for different reasons.
You can use fine-grained password policies to specify multiple password policies within a single domain. You can use fine-grained password policies to apply different restrictions for password and account lockout policies to different sets of users in a domain.
For example, you can apply stricter settings to privileged accounts and less-strict settings to the accounts of other users. In other cases, you might want to apply a special password policy for accounts whose passwords are synchronized with other data sources.
Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups. By default, only members of the Domain Admins group can set fine-grained password policies. However, you can also delegate the ability to set these policies to other users. The domain functional level must be Windows Server 2008.
Fine-grained password policies do not interfere with custom password filters that you might use in the same domain. Organizations that have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 can continue to use those password filters to enforce additional restrictions for passwords.

Read More

What are the new features of Windows server 2008 virtualization?

There are several new features in Windows Server virtualization that help create a scalable, secure and highly available virtualization platform as a part of Windows Server 2008. The following are some of the key components and features of Windows Server virtualization.

· Windows hypervisor. This is a very thin layer of software that leverages the Windows Server driver support and hardware assisted virtualization technology. The minimal code base with no third-party code or drivers helps create a more secure and robust base for virtualization solutions.

· 64-bit guest support. A key new feature of the Windows Server virtualization platform is the ability to support 64-bit guests. This enables organizations to virtualize more applications that are memory-intensive and benefit from the increased memory pool accessible in a 64-bit environment.

· Multiprocessor guest support. Windows Server virtualization now provides the capability to allocate multiple CPU resources to a single virtual machine and enables virtualization of multithreaded applications. This capability combined with the 64-bit guest support makes Windows Server virtualization a scalable platform for virtualization

· Migration of virtual machines. Windows Server virtualization will provide the ability to move a virtual machine from one physical machine to another with minimal downtime. This capability combined with host clustering of physical machines provides high availability and flexibility to achieve an agile and dynamic datacenter.

· New device virtualization architecture. Windows Server virtualization provides a new virtualized I/O architecture. This provides customers with high performance and low overhead.

· Offline VHD manipulation. Windows Server virtualization provides administrators with the ability to securely access files within a VHD without having to instantiate a virtual machine. This provides administrators with granular access to VHDs and the ability to perform some management tasks offline.

Read More

What are the core components of Windows Security System?

Followings are the core components that implement Windows security:
· Security reference monitor (SRM) A component in the Windows executive (\Windows\ System32\Ntoskrnl.exe) that is responsible for defining the access token data structure to represent a security context, performing security access checks on objects, manipulating privileges (user rights), and generating any resulting security audit messages.

· Local security authority subsystem (Lsass) A user-mode process running the image \Windows\System32\Lsass.exe that is responsible for the local system security policy (such as which users are allowed to log on to the machine, password policies, privileges granted to users and groups, and the system security auditing settings), user authentication, and sending security audit messages to the Event Log. The local security authority service (Lsasrv—\Windows\System32\Lsasrv.dll), a library that Lsass loads, implements most of this functionality.

· Lsass policy database A database that contains the local system security policy settings. This database is stored in the registry under HKLM\SECURITY. It includes such information as what domains are entrusted to authenticate logon attempts, who has permission to access the system and how (interactive, network, and service logons), who is assigned which privileges, and what kind of security auditing is to be performed. The Lsass policy database also stores "secrets" that include logon information used for cached domain logons and Windows service user-account logons.

· Security Accounts Manager (SAM) service: A set of subroutines responsible for managing the database that contains the usernames and groups defined on the local machine. The SAM service, which is implemented as \Windows\System32\Samsrv.dll, runs in the Lsass process.

· SAM database A database that on systems not functioning as domain controllers contains the defined local users and groups, along with their passwords and other attributes. On domain controllers the SAM stores the system's administrator recovery account definition and password. This database is stored in the registry under HKLM\SAM.

· Authentication packages These include dynamic-link libraries (DLLs) that run both in the context of the Lsass process and client processes and that implement Windows authentication policy. An authentication DLL is responsible for checking whether a given username and password match, and if so, returning to the Lsass information detailing the user's security identity, which LSASS uses to generate a token.

· Logon process (Winlogon) A user-mode process running \Windows\System32\ Winlogon.exe that is responsible for responding to the SAS and for managing interactive logon sessions. Winlogon creates a user's shell (user-interface) process when the user logs on.

· Graphical Identification and Authentication (GINA) A user-mode DLL that runs in the Winlogon process and that Winlogon uses to obtain a user's name and password or smartcard PIN. The standard GINA is \Windows\System32\Msgina.dll.

· Network logon service (Netlogon) A Windows service (\Windows\System32\ Netlogon.dll) that sets up the secure channel to a domain controller, over which security requests—such an interactive logon (if the domain controller is running Windows NT 4) or LAN Manager and NT LAN Manager (v1 and v2) authentication validation—are sent.

Read More

How is Kerberos used while accessing file share on the network? What is the background processing involved in it?

When user is already logged onto a domain and wants to access a resource located on a server within the same domain, a network logon process will take place.

In this case, the logon sequence is as follows:
1. User sends a server ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).
2. The TGS of the DC checks the authenticator, generates a server ticket, and sends it back to User (KRB_TGS_REP).
3. User sends the ticket (together with an authenticator) to the application server (KRB_AP_REQ).
4. The application verifies the ticket with the authenticator and sends back his or her authenticator to User for server authentication (KRB_AP_REP).

Read More

How do we login in domain and what happens in the background at time of logon

How does authentication and authoriztion happens in active directory?

Everything starts when User presses Ctrl+Alt+Del and User chooses to log on to the domain.
1. The client Kerberos package acting on behalf of User tries to locate a KDC service for the domain; it does so by querying the DNS service (Windows 2000 and Windows Server 2003 publish two Kerberos-specific SRV records to DNS: _kerberos and _kpasswd. The list of all published SRV records can be found on a domain controller in the "%windir%system32/config/netlogon.dns" file. The SRV DNS records are created automatically during the domain controller setup, as part of the dcpromo process).
2. Once the DC is found, User sends a Kerberos authentication request to the DC. This request authenticates User to the DC and contains a TGT request (KRB_AS_REQ).
3. The Authentication Service authenticates User, generates a TGT, and sends it back to the client (KRB_AS_REP).
Local logon process in a single domain environment.
4. The local machine where User logged on is -- just like any other resource -- a resource for which User needs a ticket. User sends a ticket request to the DC using her TGT (together with an authenticator) (KRB_TGS_REQ).
5. The TGS of the DC checks the TGT and the authenticator, generates a ticket for the local machine, and sends it back to the User (KRB_TGS_REP).
6. On User’s machine, the ticket is presented to the Local Security Authority, which will create an access token for the User. From then on, any process acting on behalf of User can access the local machine's resources.

Read More

What is restartable feature of AD DS?

Restartable AD DS reduces the time that is required to perform certain operations. AD DS can be stopped so that updates can be applied to a domain controller; also, administrators can stop AD DS to perform tasks such as offline defragmentation of the Active Directory database, without restarting the domain controller. Other services that are running on the server and that do not depend on AD DS to function, such as Dynamic Host Configuration Protocol (DHCP), remain available to satisfy client requests while AD DS is stopped.


In Active Directory in the Microsoft® Windows® 2000 Server operating system and Windows Server® 2003 operating system, offline defragmentation of the database required a restart of the domain controller in Directory Services Restore Mode. Applying security updates also often required a restart of the domain controller.

In Windows Server 2008, however, administrators can stop and restart AD DS. This makes it possible to perform offline AD DS operations more quickly.

Restartable AD DS adds minor changes to existing MMC snap-ins. A domain controller running Windows Server 2008 AD DS displays Domain Controller in the Services (Local) node of the Component Services snap-in and the Computer Management snap-in. By using either snap-in, an administrator can easily stop and restart AD DS the same way as any other service that is running locally on the server.


The three possible states for a domain controller running Windows Server 2008 are as follows:

•
AD DS Started. In this state, AD DS is started. For clients and other services running on the server, a Windows Server 2008 domain controller running in this state is the same as a domain controller running Windows 2000 Server or Windows Server 2003.
•
AD DS Stopped. In this state, AD DS is stopped. Although this mode is unique, the server has some characteristics of both a domain controller in Directory Services Restore Mode and a domain-joined member server.
As with Directory Services Restore Mode (DSRM), the Active Directory database (Ntds.dit) on the local domain controller is offline. Another domain controller can be contacted for logon if one is available. If no other domain controller can be contacted, you can use the DSRM password to log on to the local domain controller in DSRM.
As with a member server, the server is joined to the domain. This means that Group Policy and other settings are still applied to the computer. However, a domain controller should not remain in this state for an extended period of time because in this state it cannot service logon requests or replicate with other domain controllers.
•
Directory Services Restore Mode. This mode (or state) is unchanged from Windows Server 2003.

Read More

What are Preliminary AD DS Installation Steps and what all commands are available to upgrade the Forest schema to accept Windows server 2008?

For new Forest:
. Strong password.
. Correct Network settings.
. Latest Security updates.


For Existing Forest:
. Extend Schema using adprep/forestprep
. For a windows 2000 domain adprep/domainprep /gpprep
. For a windows 2003 domain adprep/domainprep
. RODC: adprep /rodcprep

Preliminary AD DS Installation Steps



You need to consider following steps before the first Windows Server 2008 domain controller is introduced into an existing forest.

1. If the domain controller is the first Windows Server 2008 domain controller in the forest, the forest must be prepared for Windows Server 2008 by extending the schema, running adprep /forestprep, on the schema master.

2. If the domain controller is the first Windows Server 2008 domain controller in a Windows 2000 Server domain, the domain must be prepared by running adprep /domainprep /gpprep on the infrastructure master. The infrastructure master is responsible for updating references from objects in its domain to objects in other domains. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.

3. If the domain controller is the first Windows Server 2008 domain controller in a Windows Server 2003 domain, the domain must be prepared by running adprep /domainprep on the infrastructure master.

4. The first Windows Server 2008 domain controller in an existing Windows 2000 Server or Windows Server 2003 domain cannot be created as an Read Only Domain Controller (RODC). After a Windows Server 2008 domain controller exists in the domain, subsequent Windows Server 2008 domain controllers can be created as RODCs. The forest and domain functional level of Windows Server 2003 is required for creating an RODC. When installing the first RODC in the forest, the forest must be prepared by running adprep /rodcprep

Read More

What are the events that trigger Urgent Replication?

Events That Trigger Urgent Replication
Certain important events trigger replication immediately, overriding existing change notification. Urgent replication is implemented immediately by using RPC/IP to notify replication partners that changes have occurred on a source domain controller. Urgent replication uses regular change notification between destination and source domain controller pairs that otherwise use change notification, but notification is sent immediately in response to urgent events instead of waiting the default period of 15 seconds (or 300 seconds on domain controllers that are running Windows 2000).
Urgent Active Directory replication is always triggered by certain events on all domain controllers within the same site. When you have enabled change notification between sites, these triggering events also replicate immediately between sites.
Between Windows Server 2003–based and Windows 2000–based domain controllers in the same site, immediate notification is caused by the following events:
• Assigning an account lockout, which a domain controller performs to prohibit a user from logging on after a certain number of failed attempts.
• Changing the account lockout policy.
• Changing the domain password policy.
• Changing a Local Security Authority (LSA) secret, which is a secure form in which private data is stored by the LSA (for example, the password for a trust relationship).
• Changing the password on a domain controller computer account.
• Changing the relative identifier (known as a “RID”) master role owner, which is the single domain controller in a domain that assigns relative identifiers to all domain controllers in that domain.

Read More

What is prerequisites for deploying an RODC in your domain?

RODC Prerequisites:

The prerequisites for deploying an RODC (Read Only Domain Controller) are as follows:

• The domain controller that holds the primary domain controller (PDC) emulator operations master role for the domain must be running Windows Server 2008. This is necessary for creating the new krbtgt account for the RODC and for ongoing RODC operations.

• The RODC needs to forward authentication requests to a global catalog server running Windows Server 2008 in the site that is closest to the site with the RODC. The Password Replication Policy is set on this domain controller to determine if credentials are replicated to the branch location for a forwarded request from the RODC.

• The domain functional level must be Windows Server 2003 so that Kerberos constrained delegation is available. Constrained delegation is used for security calls that need to be impersonated under the context of the caller.

• The forest functional level must be Windows Server 2003, so that linked-value replication is available. This provides a higher level of replication consistency.

• You must run adprep /rodcprep one time in the forest. This will update the permissions on all of the DNS application directory partitions in the forest to facilitate replication between RODCs that are also DNS servers.

• Multiple RODCs for the same domain in the same site are not supported because RODCs in the same site do not share information with each other. Therefore, deploying multiple RODCs for the same domain in the same site can lead to inconsistent logon experiences for users, if the writable domain controllers cannot be reached on the network.

Read More