Configuring a Read-Only Domain Controller in window Server 2008.

Consider an enterprise that is characterized by a main site and  branch offices. The branch offices connect to the main site over WAN links that might be congested, expensive, slow, or unreliable. Users in the branch office must be authenticated by Active Directory to access resources in the domain. Should a DC be placed in the branch office?

If a DC is not placed in the branch office, authentication and service ticket activities will be directed to the main site over the WAN link. Authentication occurs when a user first logs on to his or her computer in the morning. Service tickets are a component of the Kerberos authentication mechanism used by Windows Server 2008 domains.

If a DC is placed in the branch office, authentication is much more efficient, but there are several potentially significant risks.

A DC maintains a copy of all attributes of all objects in its domain, including secrets such as information related to user passwords. If a DC is accessed or stolen, it becomes possible for a determined expert to identify valid user names and passwords, at which point the entire domain is compromised. At a minimum, you must reset the passwords of every user account in the domain. Because the security of servers at branch offices is often less than ideal, a branch office DC poses a considerable security risk.

A second concern is that the changes to the Active Directory database on a branch office DC replicate to the hub site and to all other DCs in the environment. Therefore, corruption to the

branch office DC poses a risk to the integrity of the enterprise directory service. For example, if a branch office administrator performs a restore of the DC from an outdated backup, there

can be significant repercussions for the entire domain.

The third concern relates to administration. A branch office domain controller might require maintenance, for example, a new device driver. To perform maintenance on a standard domain controller, you must log on as a member of the Administrators group on the domain controller, which means you are effectively an administrator of the domain. It might not be appropriate to grant that level of capability to a support team at a branch office.

Read-Only Domain Controllers

The RODC is designed specifically to address the branch office scenario. An RODC is a domain controller, typically placed in the branch office, that maintains a copy of all objects in the domain and all attributes except secrets such as password-related properties. When a user in the branch office logs on, the RODC receives the request and forwards it to a domain controller in the main site for authentication.

You are able to configure a password replication policy (PRP) for the RODC that specifies user accounts the RODC is allowed to cache. If the user logging on is included in the PRP, the RODC caches that user’s credentials, so the next time authentication is requested, the RODC can perform the task locally. As users who are included in the PRP log on, the RODC builds its cache of credentials so that it can perform authentication locally for those users.

Because the RODC maintains only a subset of user credentials, if the RODC is compromised or stolen, the effect of the security exposure is limited; only the user accounts that had been

cached on the RODC must have their passwords changed. Writable domain controllers maintain a list of all cached credentials on individual RODCs. When you delete the account of the stolen or compromised RODC from Active Directory, you are given the option to reset the passwords of all user accounts that were cached on the RODC.

The RODC replicates changes to Active Directory from DCs in the main site. Replication is one way (from a writable domain controller to a RODC); no changes to the RODC are replicated to any other domain controller. This eliminates the exposure of the directory service to corruption resulting from changes made to a compromised branch office DC. Finally, RODCs, unlike writable DCs, have a local Administrators group. You can give one or more local support personnel the ability to maintain an RODC fully, without granting them the equivalence of domain administrators.

Installing an RODC

An RODC must replicate domain updates from a writable domain controller running Windows Server 2008. It is critical that an RODC is able to establish a replication connection with a writable Windows Server 2008 domain controller. Ideally, the writable Windows Server 2008 domain controller should be in the closest site to the main site. In the following lesson we will create an RODC called Branchrodc attached to the Es-net domain. We will create a branch office security group and users, then configure a Password Replication Policy (PRP)

Type dcpromo in the run box and click OK. Check if Active Directory binaries are installed. Active Directory installation wizard starts. Click Next to continue. Operating System compatibility page click Next. Ensure add a domain controller to an existing domain is checked and click Next.

Enter domain you wish to join and specify credentials, then click Next. Select domain then click Next. Select site for new domain controller and click Next. Ensure Global Catalog and Read-only domain controller (RODC) are checked and click Next. Click Next. Type in and confirm restore mode password and click Next. Review selections and click Next. Installation of Active Directory begins. Installation completed. Click Finish. To complete the install click Restart Now. Enjoy your reading :)

Auditing Authentication in Windows Serve 2008

When a user logs on to any computer in the domain using his or her domain user account, a domain controller authenticates the attempt to log on to the domain account. This generates an account logon event on the domain controller.

The computer to which the user logs on for example, the user’s desktop generates a logon event. The computer did not authenticate the user against his or her account; it passed the account to a domain controller for validation. The computer did, however, allow the user to log on interactively to the computer. Therefore, the event is a logon event. When the user connects to a folder on a server in the domain, that server authorizes the user for a type of logon called a network logon. Again, the server does not authenticate the user; it relies on the ticket given to the user by the domain controller. But the connection by the user generates a logon event on the server.

Open Group Policy Management. Expand Domain Controllers OU. Right Click the Default Domain Controllers Policy. Select Edit. Expand Computer Configuration>Windows Settings>Security Settings. Click Audit Policies. Right click Audit account logon events and select Properties. Select Define these policy settings and select Success and Failure. Click OK. Right click Audit logon events and select Properties. Select Define these policy settings and select Success and Failure. Click OK. Both audit policies are enabled. Close the dialogue box. In order to test the audit policy the Administrator will attempt to log on with an incorrect password. Close Group Policy Management and try it.

After some failed logons check event viewer security log. Note the Audit Failures. Double click an event for more detail. These are the event’s details. You can also access Microsoft’s online database for more information about any event. Close all open dialogue boxes to return to the desktop. Enjoy your reading :)

Configuring Password and Lockout Policies in windows Server 2008

In a Windows Server 2008 domain, users are required to change their password every 42 days, and a password must be at least seven characters long and meet complexity requirements including the use of three of four character types: uppercase, lowercase, numeric, and non alphanumeric.

hree password policies—maximum password age, password length, and password complexity—are among the first policies encountered by administrators and users alike in an Active Directory domain. Rarely do these default settings align precisely with the password security requirements of an organization. Your organization might require passwords to be changed more or less frequently or to be longer.
There are exceptions to every rule, and you likely have exceptions to your password policies.
To enhance the security of your domain, you can set more restrictive password requirements for accounts assigned to administrators, for accounts used by services such as Microsoft SQL Server, or for a backup utility. In earlier versions of Windows, this was not possible; a single password policy applied to all accounts in the domain.In this lesson, you will learn to configure fine-grained password policies, a new feature in Windows Server 2008 that enables you to assign different password policies to users and groups in your domain.

If the new password meets requirements, Active Directory puts the password through a mathematical algorithm that produces a representation of the password called the hash code. The hash code is unique; no two passwords can create the same hash code. The algorithm used to create the hash code is called a one-way function. You cannot put the hash code through a reverse function to derive the password. The fact that a hash code, and not the password itself, is stored in Active Directory helps increase the security of the user account.

The password settings configured in the Default Domain Policy affect all user accounts in the domain. The settings can be overridden, however, by the password-related properties of the individual user accounts. On the Account tab of a user’s Properties dialog box, you can specify settings such as Password Never Expires or Store Passwords Using Reversible Encryption. For example, if five users have an application that requires direct access to their passwords, you can configure the accounts for those users to store their passwords, using reversible encryption.

In this lesson, you will learn how to implement your enterprise’s password and lockout policies by modifying the Default Domain Policy Group Policy object (GPO).

Click Group Policy Management. Expand the domain. Right Click Default Domain policy and click Edit. Expand – Computer Configuration>Policies>Windows Settings>Security Settings. Expand Account Policies. Select Password Policies. Right Click Maximum password age and select Properties. Change Password will expire in: to 30 days. Click OK. Maximum password age is now set to 30 days. Next select Account lockout policy and right click Account lockout threshold and select Properties. Set invalid logon attempts to 3. When you Click OK Windows will suggest values for the remaining policies, Click OK to accept these. The suggested values can be changed later. Click OK. The Account lockout policy is now configured. All open dialogue boxes can now be closed.

Fine-Grained Password and Lockout Policy

You can also override the domain password and lockout policy by using a new feature of Windows Server 2008 called fine-grained password and lockout policy, often shortened to simply fine-grained password policy.
Fine-grained password policy enables you to configure a policy that applies to one or more groups or users in your domain. To use fine-grained password policy, your domain must be at the Windows Server 2008 domain functional level. To raise the domain functional level open Active Directory Users and Computers.

Right click the domain and select Raise domain functional level. Select Windows Server 2008 and click Raise. Warning Raising the domain functional level cannot be reversed. Click OK to continue. Click Close to complete.

Fine-Grained Password and Lockout Policy

The settings managed by fine-grained password policy are identical to those in the Password Policy and Accounts Policy nodes of a GPO.
However, fine-grained password policies are not implemented as part of Group Policy, nor are they applied as part of a GPO. Instead, there is a separate class of object in Active Directory that maintains the settings for fine-grained password policy: the password settings object (PSO).

Most Active Directory objects can be managed with user-friendly graphical user interface (GUI) tools such as the Active Directory Users and Computers snap-in. You manage PSOs, however, with low-level tools, including ADSI Edit.

In this exercise, you will create a PSO that applies a restrictive, fine-grained password policy to users in the Domain Admins group. Before you proceed with this exercise, confirm that the Domain Admins group is in the Users container. If it is not, move it to the Users container.

Click Administrative tools>ADSI Edit. Expand the domain. Expand CN=System. Select CN=Password Settings Container. Right click and select New>Object. Click Next to continue. Type a name for the new object and click Next.

PSO Precedence and Resultant PSO

A PSO (Password Settings Object) can be linked to more than one group or user, an individual group or user can have more than one PSO linked to it, and a user can belong to multiple groups. So which fine grained password and lockout policy settings apply to a user? One and only one PSO determines the password and lockout settings for a user; this PSO is called the resultant PSO. Each PSO has an attribute that determines the precedence of the PSO. The precedence value is any number greater than 0, where the number 1 indicates highest precedence. If multiple PSOs apply to a user, the PSO with the highest precedence (closest to 1) takes effect.

Set the Precedence value to 1 and click Next. Type False The password is not stored using reversible encryption and click Next. Type 30 The user cannot reuse any of the last 30 passwords and click Next. Type True Password complexity rules are enforced and click Next. Type 10 Password must be at least 10 characters in length and click Next. Type 1:00:00:00. A user cannot change his or her password within one day of a previous change. The format is d:hh:mm:ss (days, hours, minutes, seconds) and click Next. Type 45:00:00:00. The password must be changed every 45 days and click Next. Type 5. Five invalid logons within the time frame specified by (the next attribute) will result in account lockout and click Next. Type 0:01:00:00. Five invalid logons (specified by the previous attribute) within one hour will result in account lockout and click Next. Type 0:01:00:00. An account, if locked out, will remain locked for one hour or until it is unlocked manually. A value of zero will result in the account remaining locked out until an administrator unlocks it and click Next. The attributes listed are required. After clicking Next on the msDS-LockoutDuration attribute page, you will be able to configure the optional attribute. Click the More Attributes button.

In the Edit Attributes box, type CN=DomainAdmins,CN=Users,DC=es-net,DC=co,DC=uk
and click Set. Click OK. The new PSO is now active.

Resultant PSO

To identify the PSO that controls the password and lockout policies for an individual user.

Open the Active Directory Users And Computers snap-in.
Click the View menu and make sure that Advanced Features is selected.
Expand the domain and click the Users container in the console tree.
Right-click the Administrator account and choose Properties.
Click the Attribute Editor tab.
Click the Filter button and make sure that Constructed is selected. The attribute you will locate in the next step is a constructed attribute, meaning that the resultant PSO is not a hard-coded attribute of a user; rather, it is calculated by examining the PSOs linked to a user in real time.
In the Attributes list, locate msDS-ResultantPSO.
Identify the PSO that affects the user.
The Domain Admins PSO that you created is the resultant PSO for the Administrator account. Enjoy your reading.

Facebook Apps Money Change (July 2013 Breaking Changes)

Start from this morning untill July 2013 facebook will announce new feature for all user who use one of their social plug in to chaange their notification.

All users need to fix it on time for their use of Apps. Please see the screen shoot for an example to change your apps: 

 Screen 1: 

Screen 2: 

Enjoy your Breaking Changes  From FaceBook. :D

How to find Product ID on your windows 8

Hello everyone today i will show you how to find Microsoft ID products in windows 8 in your own computers.

Did you that you can find Product ID for your windows 8 Microsft products just follow my tutorial:

Now let start:

1: for user useing windows 8

windows key + pause/break bottom to open system properties than you will see the prompt windows show up( see the picture bellow)

2. Scroll down to the buttom, and look under Windows is activated you will see the Products ID as show : example: 00178-70000-00011-AA579 ( see the picture bellow)

Enjoy it: :D

Fix windows live and tweak.

Some of the editors migrated their home PCs from Windows XP or Vista to Windows 7, and we encountered a little glitch with Windows Live Mail that drove us bananas for the better part of an afternoon. We’d like to save you the same grief.

Our e-mails imported fine from XP’s Outlook Express, but we found that in the “Sent items” view in Live Mail, it was impossible to tell at a glance to whom we sent our mails. That’s because the columns in the default view didn’t include the one for the “To:” field. (Your mileage may vary. The missing “To:” field didn’t happen in another install we performed, but the next step—the grey-out issue—did.)

Simple enough, we thought—it’s easy to customize the view to show the “To:” field. You’d just hit Alt, go the View menu, choose the Columns item, and…hey wait a minute, the Columns menu option is greyed out! Hmmm. All we wanted was to restore this little column:

An afternoon of tweaking and searching later, we discovered that, strangely enough, repositioning the preview pane (the region of the screen that shows you a preview portion of a selected e-mail) was the only thing that would “un-grey” the Columns item on the View menu. This is likely a bug, and we’d expect it to be fixed before long. But how to work around it, for now?

In your Sent Mail view in Live Mail, hit Alt to bring up the menu bar, click View > Layout, and in the Layout dialog box, change the Reading pane (Mail) entry to At the bottom of the message list. (You can also uncheck the Show the reading pane box if you’d like to get rid of the pane altogether.) Hit OK, and you should be able to access the Columns entry in the View menu to tweak the columns that are displayed.

Download Windows Live to restore common windows application.

If you’re a Windows XP user who has just migrated to Windows 7, you’re likely to notice a few old friends missing: notably, a mail client (Outlook Express) and Windows Movie Maker. And if you’re using Vista, the Windows Mail, Movie Maker, and Photo Gallery apps might be conspicuous by their absence in 7.

In Windows 7, Microsoft has moved these programs off-OS and made them part of a downloadable package of apps called “Windows Live Essentials.” (Why, if they’re “Essentials,” they’re not included as part of the OS is another story, though.) This is the Live Essentials page.

11-Live-Essentials

You’ll need to sign up for a free Windows Live account to download the lot. (You may well already have one.) You may or may not need Live Essentials, depending on the e-mail client you tend to use and whether you already own some favorite photo- and video-editing software, but we think the download is worth the trouble, regardless. For one thing, the Windows Photo Gallery app has been bulked up a bit from Vista’s; it now has more editing functions, so it can be a time saver versus launching a full-featured photo editor. And Windows Movie Maker, as in Vista, incorporates the ability to burn a DVD Video direct from the app, so no need to fire up Nero, Roxio, or another big burning app for straightforward jobs. Check out the Live Essentials pack at http://download.live.com.