Windows Server









19 Smart Tips for Securing Active Directory


Active Directory

Group Policy


Does Active Directory keep you up at night? One could easily understand why. It is most likely the largest and most critical distributed system in your enterprise. Along with disaster recovery, Active Directory® security is at the top of the list of topics that gnaw away at an administrator’s sleep.

But there’s a lot you can do to enhance your Active Directory security, and you’ve probably already taken some steps. What follows is a list of tips you can use to help you make your Active Directory installation more secure. First I’ll cover administrative security, then passwords and group security, then wrap up with tips for domain controller security.


1. Document What You Have

The very first step you need to take is to document your Active Directory configuration. It’s not very exciting work, but you can’t tell where you need to go if you don’t know where you are right now. A good place to start is with the high-level structures like forest and domain configuration, organizational unit (OU) structure, top-level directory security, and existing trust relationships. Document your site topology by listing the sites, configuration settings for each site, site links and their settings, the list of subnets and their settings, and any manually created connection objects and their settings. Document your Group Policy Objects (GPOs) with a Group Policy utility like the Group Policy Management Console (GPMC), available from Microsoft downloads and included in Windows Server™ 2003 R2. The documentation you create should include password and audit policies, and don’t forget to include what the GPOs are linked to and who has rights on them. Be sure you have a list of all changes you’ve made to the Active Directory schema, preferably in the form of a Lightweight Directory Interchange Format (LDIF) file. There’s even a GPMC script included in the download to help you get started. It is located in the %programfiles%\gpmc\scripts directory and is called GetReportsForAllGPOs.wsf.

While you’re at it, also list your domain controllers and their names, their OS versions, and virus scanning software and their versions. Record the backup methods you’re using and how often they run, along with how long you keep the backups. If you use disk-based backups, record where you securely keep the backup files. If you use Windows® DNS, use DNSCMD and DNSLINT to document its configuration. Note whether it’s integrated with Active Directory, whether you use application partitions, and how they are configured.


2. Control Your Administration

Active Directory security begins right at the top—your administration model. Controlling your administration is the single most important step in securing your forest and it’s also probably the hardest. Everyone wants to own a piece of Active Directory, but a well-secured forest model can’t allow this. If your company’s installation is like most, your logical Active Directory design is already set, so you have to work within its constraints. If not, you have the opportunity to build Active Directory from the start.

The forest is the only true security boundary within Active Directory. Domains should be used to facilitate your company’s IT support infrastructure and replication, and OUs should be used to delegate administration within a domain. If you have hard security constraints between two parts of your company, consider implementing another forest. See "Multiple Forest Considerations in Windows 2000 and Windows Server 2003" for recommendations. If necessary, add a security-filtered forest trust to communicate with your first forest (see "Planning and Implementing Federated Forests in Windows Server 2003" for more information). If your domains are already administered by different groups, realize that administrative access to any domain controller in the forest can jeopardize the entire forest. As a result, you need to work closely with the administrative teams of the other domains to ensure you have a uniform domain controller (DC) administration model across the forest. For more detail on this topic, read "Design Considerations for Delegation of Administration in Active Directory".


3. Limit the Number of Administrators

Within your forest, you need to do everything you can to limit the number of administrators. Though the Active Directory security model is much better than it was in Windows NT® 4.0, it still has a weakness: you can’t fully administer a domain controller without being an administrator of the domain. This means that in a basic Active Directory implementation, computer operators in locations that contain DCs are usually members of Domain Admins so they can perform all maintenance functions on these servers. Don’t do this! You’ve handed the keys to your Active Directory forest to a potentially large number of employees with unknown backgrounds and security qualifications. Instead, follow the time-honored practice of determining requirements first and then creating a solution based on these requirements. Meet with operations management to figure out exactly what tasks they need to perform on DCs. Then, design a solution using a combination of Group Policy and third-party tools to grant them as many rights as possible without elevating them to Domain Admins.

Finally, your administration team must assume the tasks you can’t securely delegate to operations. This is a very touchy area because you’re taking away responsibilities from operations, but you’ll have the big stick of information security on your side.


4. Test Group Policy Settings

This is a good opportunity to say a few words about Group Policy. It’s the single most powerful tool for controlling your forest’s security. Precisely because it’s so powerful, however, you need to make sure you test these settings in a controlled environment before rolling them out. You can use a duplicate test-bed environment, be it physical or virtual (through the use of virtualization software such as Virtual Server 2006). You can implement these policies in stages by first linking new security-focused GPOs to individual OUs, then to the entire domain.


5. Use Separate Administrative Accounts

Once you’ve limited the number of administrators, make sure all employees who perform operations with elevated privileges use separate administrative accounts. These accounts should have a naming convention that’s different from standard accounts and should reside in their own OU so you can apply unique GPOs to them. You can group these accounts by the roles they perform and assign rights to these groups rather than to individuals. For example, helpdesk members responsible for account management should have their administrative accounts in a group named "<domain name> Account Admins", and this group should be added to the Account Operators built-in group.


6. Restrict Elevated Built-In Groups

If your security model follows the recommendations I just outlined, it’s relatively easy to put all elevated built-in groups into Group Policy’s Restricted Groups feature. This will ensure that the group’s membership is enforced every five minutes, limiting the chance that a rogue administrator will inject their account into it. Use Restricted Groups to keep groups like Schema Admins empty and to keep Enterprise Admins very small.


7. Use a Dedicated Terminal Server for Administration

Service administrators (responsible for running core Active Directory services like DCs, sites, and the schema) should perform all their tasks from dedicated terminal server administration points (TSAPs) rather than from their desktops. This is a much more secure practice that minimizes any leaking of desktop malware, makes working with a separate administrative account much less cumbersome and provides a locked-down, customized administration point. Keep these TSAPs in their own OU, and use GPOs to prevent Internet access, restrict logon locally to administrative accounts only, increase auditing procedures, and implement a password-protected screen saver. Upgrading your TSAP to Windows Server 2003 will cause its Active Directory administration tools to sign and encrypt Lightweight Directory Access Protocol (LDAP) traffic between itself and your Windows Server 2003 DCs.


8. Disable Guest and Rename Administrator

Basic account security measures are to disable the guest account and rename the administrator account. You may have already done this. Either way, don’t forget to also remove the default description of these accounts, since that’s easy for bad guys to search for. Most programmatic attacks use the administrator account’s well-known Security Identifier (SID) rather than its name, so renaming Administrator is really of limited use. It does show that you’re using due diligence for security audits, however. The rename policy also can be useful for creating a honeypot Administrator account. This is an account named Administrator (after you’ve renamed the real account) that has a high level of auditing enabled. If anyone attempts to log onto this account by guessing the password, the attempt will be logged. If you have an event log monitoring utility, you can also trigger an alert.


9. Limit Access to the Administrator Account

You should severely limit the number of people who have access to the real Administrator account and password. For the highest level of security, consider the nuclear password option: two (or more) administrators generate two (or more) eight-digit, random, strong passwords separate from each other; then each admin enters his password into the password field. (For a good password generator, take a look at www.winguides.com/security/password.php.) The account now has a password that is 16-digits or longer and that requires at least two administrators to log on; one administrator can’t do it alone.


10. Watch the DSRM Password

An often overlooked but important password is the Directory Service Restore Mode (DSRM) password on domain controllers. The DSRM password, unique to each DC, is used to log onto a DC that has been rebooted into DSRM mode to take its copy of Active Directory offline. You need to update the DSRM password regularly because with this password a local operator can copy NTDS.DIT (the Active Directory database) off the server and reboot before anyone noticed. In early builds of Windows 2000, the only way to change the password was to log on and change it manually—impractical if you have more than two DCs. Windows 2000 Service Pack 2 introduced the SETPWD command (see the Knowledge Base article "Configure Your Server Wizard sets a blank recovery mode password") to remotely update the DSRM password. The NTDSUTIL command in Windows 2003 has the ability to change it remotely (see "How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003"). Create a script to run this operation against your DCs, and run it regularly.


11. Enforce Strong Password Rules

By now, you all know the benefits of strong passwords, but it’s probably too much to expect your users to use them willingly. To help them along, you really should enforce strong password rules in your domain (see "Enabling Strong Password Functionality in Windows 2000"). You can help your users by suggesting strategies such as the use of passphrases instead of confusing word/number/character combinations.


12. Protect the Service Account’s Password

As you know, service accounts are another sore subject. The nature of service accounts—used on application servers for the application’s service—makes a low-impact password change very difficult, and so the password is usually set to never expire. Because the account controls an important service (often on many servers), compromising the service account’s password is not something you want to happen.

Though it may be difficult to solve the password change problem, you can take steps to mitigate the risk of attack or accidental changes. Give the accounts a naming convention that identifies them as service accounts and suggests what they’re used for. Put all of these accounts into a group named something like "Service Accounts" and apply a policy to your application servers to deny the "Log on Locally" policy but allow "Log on as a Service". Keep them in their own OU so you can apply GPOs unique to their requirements.


13. Make Sure that Each DC is Physically Secure

Domain controllers make up the physical aspect of Active Directory. Distributed throughout your enterprise, each DC has its own copy of the Active Directory database NTDS.DIT. This means that one of your paramount security concerns is to make sure that each DC is physically secure. If one of them grows legs and walks off, the thief will have physical access to the directory information tree (DIT) and can run cracking programs against it to obtain usernames and passwords. Therefore, you must have a reaction plan in place to change all passwords in a domain if one of its DCs is stolen.

A proposed feature of the forthcoming version of Windows Server (code-named "Longhorn") aims to mitigate the risk from this scenario dramatically with the read-only domain controller (RODC), a DC whose DIT contains no user passwords. Users are logged on via a Kerberos referral from a full DC; you can configure the RODC to cache the passwords of users who use it for authentication. In a branch office scenario, only the branch office’s users will have their passwords cached on the RODC so if it’s compromised they’re the only passwords that must be changed immediately. The RODC caching configuration is very flexible; it even includes a way to determine who had their password cached on it. As with all discussion of prerelease software, though, this is subject to change.


14. Minimize Unnecessary Services and Open Ports

The Windows Server 2003 SP1 Security Configuration Wizard can quickly harden your DCs in this aspect by stepping you through a wizard to lock it down.

One attack to be wary of—a denial of service of sorts—fills the available disk space on a DC. There are two ways this attack can be executed. The first is by attempting to flood Active Directory with objects. Because Active Directory is hugely scalable, it is unlikely to crash in this scenario, but flooding Active Directory with objects will increase the size of the database until it fills the disk partition. Besides ensuring the DIT is on a partition with lots of free space, consider implementing directory quotas via DSMOD PARTITION or DSMOD QUOTA. This will prevent any one security principal from adding too many objects to the directory.

Another denial of service attack has to do with flooding the SYSVOL folder with files, causing it to fill up the boot partition, and crashing the DC. You can’t use a quota system in this case, but you can create a simple reserve file or files to take up existing free disk space. If you encounter this type of disk-filling situation, simply erase reserve files, one at a time, to maintain free disk space until you resolve the root cause. You can easily create reserve files with the FSUTIL FILE CREATENEW command.


15. Make the DC Time Source Secure

Because Active Directory depends on Kerberos, it’s very sensitive to time variations between its DCs. This is especially true in trusts between forests because they may rely on different time hierarchies. By default, the PDC operations master in the root domain is the reference to which all other DCs in the forest look for accurate time. What time source does this DC look to for accurate time? Is it secure?


16. Audit Important Events

You must enable auditing in a domain-level GPO, with no override, to ensure every system in your domain is tracking important events. You should audit failed logons, successful and failed account management, object access, and policy change. Use the same GPO to boost the security log size, because with the increased auditing you’ll need it.


17. Use IPsec

Many organizations have dragged their feet on the implementation of IPsec because of the complex rules you must build, but it’s relatively easy to implement for inter-DC communication only. For communications from DCs to clients, there are a number of options to consider. Windows Server 2003 DCs by default have SMB signing enabled, which means they sign all their communications to the client to prevent spoofing. Its policy is listed as "Microsoft network server: Digitally sign communications (always)". Be aware of this change when you upgrade, and don’t disable it if you don’t have to.


18. Don’t Store LAN Manager Hash Values

You should try to rid yourself of LM (Lan Manager) password hashes if possible; many password crackers attack the weak LM hash and then deduce the stronger NTLM hash. The policy you need is "Do Not Store LAN Manager Hash Value on Next Password Change". Also consider enabling "Send NTLM v2 response only, refuse LM and NTLM". Most down-level clients can be configured to use NTLMv2. This may not be possible for Active Directory installations in factory environments or other installations where embedded Windows is used. Test these settings carefully because they can break down-level clients. It’s important to remember that these clients not only include Windows NT 4.0 and Windows Me, but also other Server Message Block (SMB)-enabled network clients like network attached storage (NAS) devices, UNIX clients running Samba, or embedded Windows devices like factory station controllers. The Knowledge Base article "Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments" lists recommendations for most DC security settings and user rights.


19. Don’t Forget Your Business Practices

Handle emergencies and document procedures for facing situations like compromised passwords, general Active Directory attacks, and Active Directory disaster recovery. Microsoft has done much of this work for you in "Best Practice Guide for Securing Active Directory Installations", and "Best Practices: Active Directory Forest Recovery".






How to reset security settings back to the defaults



Over the life of an operating system install, configuration changes can occur that prevent the operating system or applications from functioning correctly. Symptoms that can be caused by overly restrictive security settings include but are not limited to:

· OS, service or application startup failures
· Authentication or authorization failures
· Resource access failures on the local or a remote computer

Operations that can make changes to security settings include but are not limited to:
· OS upgrades, QFE service pack and application installs
· Group policy changes
· User rights assignments
· Security templates
· The modification of security settings in Active Directory and the registry and other databases
· The modification of permissions on objects in AD, the file system, the Windows registry

Note that the security settings can be defined on the local, a remote computer, an interoperability mismatch between the local and a remote computer.

When a formerly working installation suddenly fails, a natural troubleshooting step is to return to the last working configuration that existed when the operating system, service or application last worked, or in an extreme case, return the operating system to its out-of-the-box configuration.

This article describes supported and unsupported methods to undo or rollback changes to the following elements:
· Permissions in the Registry, File System and Services.
· User rights assignments
· Security policy
· Group membership

Limitations of importing default security templates:

The previous version of this article states a method to use the “secedit /configure” command with the caveat that the procedure does not restore all security settings that are applied when you install Windows and may result in unforeseen consequences.

The use of “secedit /configure” to import the default security template, dfltbase.inf, is unsupported nor is it a viable method to restore default security permissions on Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 computers.

Beginning with Windows Vista, the method to apply the security during operating system setup changed. Specifically, security settings consisted of settings defined in deftbase.inf augmented by settings applied by the operating installation process and server role installation. Because there is no supported process to replay the permissions made by the operating system setup, the use of the “secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose” command line is no longer capable of resetting all security defaults and may even result in the operating system becoming unstable.

For Microsoft Windows 2000, Windows XP or Windows Server 2003 computers, the “secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose” command is still supported in the very few scenarios where security settings need to be restored using the secsetup.inf template. Since importing the Secsetup.inf or any other template only resets what’s defined in the template and does not restore external settings, this method may still not restore all operating system default, including those that may be causing a compatibility problem.

The use of “secedit /configure” remains fully supported for importing custom templates.

The following is a list of supported methods (in a loose order of preference) to restore the Windows system to its previously working state.

1. Restore using System State : (For all Windows clients/servers)

If you have a System State backup that was created for the particular Windows system prior to the incident, use the same to restore the security settings to a working state. Any changes to the applications on the system since the system state may need to be reapplied for successful recovery. This may not be helpful to restore security settings on application related data or any non-operating system files. You may need a Complete System backup including the system state to restore it back to its original state

2. Restore using System Restore:(For Windows client operating systems only)

The built-in System Restore feature automatically creates restore points at regular intervals and when applications are added via supported installer methods. Each restore point contains the necessary information needed to restore the system to the chosen system state. This method can be used to recover the system back to a specific state. As mentioned earlier in the previous method, this may not be helpful to restore security settings on application data and a Complete System backup may be needed for the same.

3. Restore using a preconfigured template:

For systems built with a template, you can use Security Configuration Wizard if a template was created for the problem machine.

4. Restore file permissions only:

For file permissions, you can use the built in command line tool ICACLS/restore to restore file security that has been backed up using the /save switch on the same machine from a prior working state. This method can be used to compare the results from an identical working machine to a failing one.

When none of the above methods apply or no backup is available from which to restore, please undo the change by following your change control list or refer to the
troubleshooting section of this article to a specific security setting or by process of elimination.

Here is a table comparing the methods mentioned earlier.


Supported operating systems



Pre-work needed

Windows Backup

All Windows Servers/Clients

Can be used to backup data & restore system state

Potentially Large data set to manage. Also, you may need to replay changes after the backup that was restored.


System Restore

All Windows clients –Windows XP, Windows Vista, Windows 7

Can be configured to perform automatic system state backups

Doesn’t restore application data which may be inadvertently changed.


Security Configuration Wizard

Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2

Can provide a template to restore/apply security

Only applies or views data contained within the template used


ICACLS /Restore

Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2

Useful for backing up NTFS file permissions for reuse later if needed

It currently doesn’t offer saving permissions for other locations such as registry, services etc.


Troubleshooting methods

Windows XP, Windows Vista, Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2

Useful when none of the above mentioned tools/backup are available

This may not put the entire machine configuration in its original state before the permissions change occurred. Also, undoing such changes may break dependencies set by an application or OS component.



More Information

The following Security parameters may need to be addressed to resolve a permissions issue. These are parameters that are defined within security templates:

Area Name



Local policy and domain policy for the system. This includes account policies, audit policies, and other policies.


Restricted group settings for any groups that are specified in the security template.


User logon rights and granting of permissions.


Security on local registry keys.


Security on local file storage.


Security for all defined services.

The following tools are available for troubleshooting the different security areas:

1. SecurityPolicy (Account Policies, Audit Policies, Event Log Settings and Security Options):

Security Configuration and Analysis
Secedit.exe /export

2. Group_Mgmt

3. User_Rights
Security Configuration and Analysis

4. RegKeys
Security Configuration and Analysis
Process Monitor

5. Filestore
Security Configuration and Analysis
Process Monitor

6. Services
Security Configuration and Analysis
Process Monitor

Following are some additional details regarding the usage of each of the tools listed above.

RSOP (Resultant Set of Policy)

Resultant Set of Policy (RSoP) is an addition to Group Policy that makes policy implementation and troubleshooting easier. RSoP is a query engine that polls existing policies and planned policies, and then reports the results of those queries. It polls existing policies based on site, domain, domain controller, and organizational unit. RSoP gathers this information from the Common Information Management Object Model (CIMOM) database (otherwise known as CIM-compliant object repository) through Windows Management Instrumentation (WMI).

What Is Resultant Set of Policy?


Using RSoP


It’s a built-in snap-in “rsop.msc” available for all supported operating systems -Windows XP or later.

Security Configuration and Analysis

Security Configuration and Analysis is a tool for analyzing and configuring local system security. Security Configuration and Analysis enables you to quickly review security analysis results and directly configure local system security. It presents recommendations alongside of current system settings and uses visual flags or remarks to highlight any areas where the current settings do not match the proposed level of security. Security Configuration and Analysis also offers the ability to resolve any discrepancies that analysis reveals. Through its use of personal databases, you can import security templates that have been created with Security Templates and apply these templates to the local computer. This immediately configures the system security with the levels specified in the template.

Analyze system security


Best practices for Security Configuration and Analysis

http://technet.microsoft.com/en-us/library/cc757894(WS.10).aspxSecedit /ExportSecedit.exe is a built-in command line tool that can be used to export the local policy or the merged policy from a Windows machine. You can export the policy state from the machine in its working state and then use the /configure switch to reapply the template onto the machine when in problem state.

For syntax and additional information, refer

NTrights.exe is a command line resource kit tool that allows you to grant or revoke user rights on a Windows computer either locally or remotely.

How to set logon user rights by using the NTRights utility


Ntrights.exe is part of the resource kit tools which can be downloaded
here .

Process Monitor is one of the Sysinternals utilities that allows for monitoring of File system, Registry, Process, Thread, and DLL activity in real time. It allows us to filter the results as well as save the results in a file for review later. This tool can be used to troubleshoot security issues with file and registry access. For example: You can filter the “result” for “denied” attempts.

For additional information, please refer the link below:


Download from here or Run Process Monitor now from Live.Sysinternals.com

AccessCheck is a command line program that can be used to check what kind of accesses specific users/groups have to resources such as files/directories/registry keys, global objects and Windows services. Click link below for details:


Download from

AccessEnumgives you a full view of your file system path and Registry hive security settings helping you for security holes and lock down permissions where necessary.


Download from

Sc.exe is a built-in command line tool that communicates with the Service Control Manager. It can be used to display information about a service start value, change or disable it. In the context of this article, you can use the command “sc sdshow Service_Name” to output the permissions on the service. Once you have the output, you can use the following KB article to interpret the same

Best practices and guidance for writers of service discretionary access control lists

Also, you can run the command “sc sdset service_name DACL_in_SDDL_format” to modify the permissions.

Additional information about this can be found in the following links:


http://technet.microsoft.com/en-us/magazine/dd296748.aspxIcacls.exeIcacls.exe is a built-in command line utility which allows to display or modify the discretionary access control lists (DACLs) on specified files/directories. “ICACLS path_name /save aclfile” can be use to export the ACL’s for the relevant path name(files/directories) into a text file and also be used to restore it back onto the files using the command “ICACLS path_name /restore aclfile”

Additional information about this can be found in the following links:







For Windows XP, type the following command, and then press ENTER:

        secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

For Windows Vista, type the following command, and then press ENTER:

        secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verbose

You receive a "Task is completed" message, and a warning message that something could not be done. You can safely ignore this message. For more information about this message, view the %windir%\Security\Logs\Scesrv.log file.

Note In Windows Vista, the defltbase.inf file is a Security configuration template for the default security. You can view the settings for this file in the following location:






What Are Access Tokens?

·        www.skar.us/thepost/system_admin/product/microsoft/windows_server/microsoft-adds/what-are-access-tokens/


·        http://technet.microsoft.com/en-us/library/cc759267.aspx


Sample command to reset security settings

Note After security settings are applied, you cannot undo the changes without restoring from a backup. If you are uncertain about resetting your security settings back to the default security settings, you must make a complete backup that includes the "System State" (the registry files). Items that are reset include NTFS file system files and folders, the registry, policies, services, privilege rights, and group membership.


To reset your operating system back to original installation default security settings:

1.    Click Start, click Run, type cmd, and then press ENTER.

2.    For Windows XP, type the following command, and then press ENTER:secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verboseFor Windows Vista, type the following command, and then press ENTER:secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /verboseYou receive a "Task is completed" message, and a warning message that something could not be done. You can safely ignore this message. For more information about this message, view the %windir%\Security\Logs\Scesrv.log file.

Note In Windows Vista, the defltbase.inf file is a Security configuration template for the default security. You can view the settings for this file in the following location:



Good Links - How to uninstall security software:

The Norton Removal Tool uninstalls all Norton 2007/2006/2005/2004/2003 products from your computer ftp://ftp.symantec.com/public/english_us_canada/removal_tools/Norton_Removal_Tool.exe


Removal of Norton (the newer version is in use, that is listed next, and this is no longer used)



For uninstalling Norton 2002 or older products:



For uninstalling McAfee AntiSpyware:



For uninstalling McAfee Personal Firewall:



For uninstalling McAfee QuickClean:



For uninstalling McAfee SpamKiller:



For uninstalling McAfee VirusScan:



For uninstalling Any McAfee Product:



Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations

Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part I



Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations: Part II





·        Event Id 1030 & 1058 USERENV App log, DCGPOFIX won't run, cannot access SYSVOL share


No TrackBacks

TrackBack URL: http://www.skar.us/site/mt-tb.cgi/2896

Leave a comment


Author Bio          ★★★★★

Author Name:         administrator
Author Location:    India
Author Rank:          Writer
Author Status:        
The Green leave stands!!



  • eBooks
  • Games
  • Softwares
  • Tools
  • Tweaks
  • Wallpapers
  • Warez
  • Games
  • Tools
  • Wallpapers
    System Administration
  • dll Center
  • Scripts
  • Tools
  • .extensions database
  • Write-up
  • Download Database
  • Jobs
  • Lists
  • Polls
  • Glossary

01000011 01110010 01100001 01100011 01101011 01111010 01101000 01100001 01100011 01101011