Thursday, April 30, 2009

How to Secure Local Administrators Group on Every Desktop

Task 1 - Remove Domain User Account

The initial task of securing the local Administrators group is to ensure that the user no longer has membership in the group. This is easier said than done, since most companies have configured the user’s domain account to have membership in this group at installation of the user’s computer.

Consider a scenario where you have resolved the issue of having users running as local Administrator and now you need to remove the domain user accounts from the local Administrators group on every desktop in your environment. You only have 10,000 desktops, laptops, and remote users.

If you create a script to perform this task, you are relying on the user to logoff and back on for the script to run. Not likely to happen on even half of the desktops, so you need another option.

As a perfect solution, you can use the Local Group – Group Policy Preference to accomplish the task within about 90 minutes of you implementing it. To get the job done, you simply need to edit a Group Policy Object (GPO) and configure the following policy:

User Configuration\Preferences\Control Panel Settings\Local Users and Groups\New\Local Group, which will open up the New Local Group Properties dialog box.

After you open up this property sheet, simply select the Remove the current user radio button. This will affect all user accounts that are in the scope of management of the GPO containing this setting. This setting will apply during the next Group Policy background refresh, which is under 90 minutes.

Task 2 - Add Domain Admins and Local Administrator

The next phase of your securing the local Administrators group is to ensure that the Domain Admins global group and the local Administrator account are both added to the local Administrators group in every desktop.

Many have attempted this by using the Restricted Groups policy that has been in Windows Active Directory Group Policy from the onset. The problem with this solution is that the Restricted Groups policy is a “delete and replace” policy, not an “append” policy. Thus, when you configure a policy to perform this task, you will wipe out the contents of the local Administrators group, replacing it with only these two accounts.

By using the Local Users and Groups policy that was described in Task 1, you can not only remove the current logged on user, but you can add in the two key accounts that will ensure you have the correct administrative privileges set on each desktop.

Task 3 - Remove Specific Accounts

The final stage of securing the local Administrators group is to ensure that only the correct accounts have membership. In many cases, there have been groups from the domain added to the local Administrators group to perform a specific task, complete a project, or perform maintenance. If these groups are no longer needed in the local Administrators group, you can simply remove them with the new Local Users and Groups policy.

In a similar fashion that you added the two accounts in task 2, you can add accounts to the policy that need to be removed. To do this, ensure that you select the "Remove from this group" option when you add the account to the policy.

Obtaining the Tools and the Rules

In order for you to take advantage of these settings, you only need to have ONE of the following on your network:

* Windows Server 2008 Server
* Windows Vista SP1, with the Remote Server Administrative Tool set installed

Both of these operating systems come with the new and improved Group Policy Management Console and Group Policy Management Editor.

The settings that are included in the new Group Policy Preferences can apply to the following operating systems:

* Windows XP SP2 and higher
* Windows Server 2003 SP1 and higher
* Windows Vista SP1 and higher
* Windows Server 2008 and higher

Source

Wednesday, April 22, 2009

Terminal Server Application Server Security

Since the actual user sessions are executed on the Terminal Servers, they figure greater into a discussion of security. The basic actions to consider when securing your Terminal Servers are:

* Using the NTFS file system.
* Configuring NTFS file permissions.
* Using GPOs to secure the user environment.
* Installing Terminal Services on a domain controller.
* Disabling the "Secondary Logon" Service.
* Remove unnecessary software
* Applying hotfixes and service packs.

Use the NTFS File System

Each user that runs a session on a Terminal Server is essentially running a remote control console session. Without an NTFS file system, you won't be able to set any file-level security permissions. Any user that is logged would be able to access files in use by other users. No mechanism would prevent users from deleting key system files, potentially crashing the server!

There is no reason not to use NTFS on your servers. Every user will be able to access NTFS files via an RDP session, even if his client is running on an operating system that cannot support NTFS, such as Windows 95.

Configure NTFS File Permissions

Using just the NTFS file system might not provide enough security with its default permissions in your environment. Even if you do not intend to fully lock-down your Terminal Servers or plan to run only initial applications, you should secure the basic file system.

When you install Terminal Services on a Windows 2003 server, you're asked whether you want to use "Full Security" or "Relaxed Security." This security setting has nothing to do with your domain configuration or your Active Directory environment. It affects only the level of security that users are given when they access your server via a Terminal Services session. To compare the two settings:

* Full Security. This setting results in Terminal Services users having the same permissions as regular members of the local users group. Regular users are not able to write to inappropriate registry keys or tamper with sensitive system files. Of course, with this level of security comes additional risk. In this case, users will sometimes not be able to run legacy applications. If you choose Full Security, you should thoroughly test your applications before enabling them for any users.
* Relaxed Security This setting results in Terminal Services users having full access to many parts of the registry and many of the system files. This alternate level of security was developed to allow older applications to execute properly.

After selecting the "permissions compatibility" mode during the installation of Terminal Services you can change it at any time via the Terminal Services Configuration MMC snap-in (Administrative Tools | Terminal Services Configuration | Server Settings | Permissions Compatibility). Setting this compatibility affects the following registry key:

Key: HKLM\System\CurrentControlSet\Control\Terminal Server\

Value: TSUserEnabled

Type: REG_DWORD

Data: 1 = Relaxed permissions. 0 = Full Security mode.
Do Not Install Terminal Services on a Domain Controller

Individual domain controllers cannot be managed separately from each other. In order for a user to be able to log on to Terminal Server sessions she must have "log on locally" (called "log on interactively" in Windows 2000) rights. If the Terminal Server is a domain controller, granting the user "log on locally" rights on the server will allow her to log on to any domain controller, even ones that are not Terminal Servers.

Also, domain controllers in Active Directory environments must be located in the "Domain Controllers" OU. You can't use OU-based Group Policy Objects if your Terminal Servers are installed on domain controllers.

Disable the "Secondary Logon" Service

Windows 2000 introduced a secondary logon ability (then called the "Run As" service) which allows users to run programs with different user rights. Within Windows Explorer, a user can shift-right-click on a file and select "Run as..." from the context menu. Alternately, a user can enter the "runas" command into the command line.

Administrators often lock down Terminal Servers for those groups of users that should be using them. The secondary logon ability allows a user who's already connected to a Terminal Server to change his credentials, potentially bypassing any security measures the administrator has configured. (If you read the rest of this chapter, you'll know better than to build servers that exhibit this weakness.)

The secondary logon ability can be disabled at the server by stopping and disabling the "Secondary Logon" service. Disable the service after you stop it, or the system will start it again when it is needed.

Remove all Non-Essential Software

Any extra applications installed on your Terminal Servers represent an increased security risk. Each installed application brings introduces more vulnerabilities. Access to extra tools, (such as those included in the resource kits) makes compromising or abusing the server easier. You shouldn't give your users more than they need to do their job.


Source: http://www.brianmadden.com/blogs/terminal_services_for_microsoft_windows_server_2003_advanced_technical_design_guide/pages/server-security.aspx

Thursday, April 16, 2009

Importance of Server Licenses in Windows 2003 Server

After the installation has been done various things might have been missed which cannot be reverted later. One of them is the Licenses to the users managing windows 2003 server. We hardly would make sure that we have selected the right option but later after this arises as a problem we would have to consult server support.

The licensing can be selected for two modes.

1 Per Server Number of concurrent sessions.
2 Per device or per user.

If the licenses have been issued to number of users per server which would mean that at a time those many concurrent sessions would be established to a server. E.g. if you have selected 10 users that means the users who are members of the terminal services group can establish only 10 sessions at a time. Now when it comes to the user licenses it means only no of users have been given right to manage the servers.

If you have already selected the no of licenses per server which means at a single point of time that many concurrent sessions would be established to your server. So in this your partner system administrator responsible for server management or DNS support engineer manage your server you would not need any specific license for him.

The licenses can also be purchased from different vendors like VeriSign. You can also give a go through to the partners to purchase licenses for managing servers. Even if their server support engineer would initiate a server managing session to your server they can purchase the required licenses. So next time you start the installation make sure take care of all things should be taken into consideration.

For Full detail Visit here

Monday, April 13, 2009

Microsoft pushes back Forefront security

Forefront Server Security for Exchange (messaging security) and Threat Management Gateway (the next version of what used to be called ISAS, Microsoft's enterprise firewall and caching software) are now expected to arrive in Q4 2009.

Management console and Forefront Security for SharePoint (portal security) are penciled in for arrival only in the first half of 2010. Forefront Client Security 2.0 (endpoint security - anti-malware and firewall - for corporate PCs) has also been delayed till the first half of next year.

In a posting on the Forefront security blog, Microsoft said the delay was needed to add improved behavior-based anti-malware protection and to improve integration with third-party security applications. The security giant expects to ship a second beta of Stirling and a release candidate prior to the final release.

Microsoft said its behavior-based anti-malware protection, which it calls Dynamic Signature Service, will help "deliver more comprehensive endpoint protection for zero day attacks" by complementing existing "advanced heuristics, dynamic translation and real time application scanning for kernel level malware with a sophisticated approach to on-demand threat mitigation".

Knock-on effects of that rather than a desire to add behavior-based detection, a term that has more to do with marketecture than technology, strike us as a more plausible reason for the delay.

Blocking malware based on what it does, rather than by recognizing its signature, is an easy enough concept to grasp but one that's frequently mired in rival marketing claims. Some vendors describe heuristic and generic detection, which many of the leading anti-virus engines have incorporated for years, as behavior-based while other make a differentiation and say the technology is the next leap forward.

Microsoft is serious about sales of security server software, and we've met several enthusiastic resellers and corporate users of ISAS over the years.

Source From: http://www.theregister.co.uk/2009/04/07/ms_forefront_postponed/

Tuesday, April 7, 2009

Protect Your Servers: Follow these Steps

If you're a small business, you may not have more than a server or two. But no matter how few or how many servers you are running, your network relies on them. They serve the applications or web pages or e-mail your team needs to do their jobs. They store valuable and/or confidential information resources. They provide a means for your customers to communicate with you, perhaps even purchase goods or services from you.

Basic Steps You Can Take

Many of the procedures already discussed will help protect your servers too. So if you haven't yet taken care of the following, make these steps a priority:

Step 1: Protect Your Desktops and Laptops

Step 2: Keep Your Data Safe

Step 3: Use the Internet Safely

Step 4: Protect Your Network

Even with those security measures addressed, there is more you can do to protect your servers.

1. Keep your servers in a safe place. Businesses must make sure that their servers are not vulnerable to physical calamities. Locate these machines in a secure, well-ventilated room, not in a hallway or under a desk where someone might inadvertently kick or spill coffee on them. Or mischievously tinker with them. Your server room should have no windows and a single door you can lock. Server cases should also be locked to prevent tampering with internal components. Know which employees have keys to the server room. You should also keep a record of the serial numbers of your servers, and mark them with your company information, so they can be identified and recovered if stolen.

2. Practice least privilege. With Windows 2000 Server, Windows Server 2003 and Small Business Server 2003, it is possible to assign users different permission levels. Rather than giving all users "Administrator" access - which is not a best practice for maintaining a secure environment for PCs or servers - you should use your servers to manage client PCs. Windows Servers can be configured to give individual users access to specific programs only, and to define which user privileges are allowed on the server. This ensures users can't make changes in areas that are critical to the server or client PC operation. It also prevents them from installing software that may introduce a virus or otherwise compromise the integrity of your network.

3. Understand your security options. Today's servers are more secure than ever, but the powerful security settings you find in Windows server products are only good if they are used appropriately and monitored aggressively. If your team doesn't have an IT specialist and/or expertise in security issues, consider hiring an outside consultant to work with you to appropriately protect your servers.


Source: Microsoft

Wednesday, April 1, 2009

Steps to Save Your Computer From Conficker Worm

The Conficker worm / virus also known as “Downadup” infection, is actually a virus code programmed in such a way that it can infect your computer and spread itself to other computers across a network automatically, without human interaction.

Most antivirus software could detect and block the Conficker worm, so if you have updated antivirus software on your computer, you are at a much lower risk of being infected by the Conficker worm.

One of its common version (Win32/Conficker.B) might spread through file sharing and via removable drives, such as USB drives. The worm adds a file to the removable drive so that when the drive is used, the AutoPlay dialog will show one additional option.

The Conficker worm can also disable important services on your computer.

Follow these steps to prevent your computer from Conflicker Worm/ Virus:-

Select the Operating system and install the security update

Enable a firewall on your computer

Windows Vista

Click Start-> Control Panel.
Click Security.
Click Turn Windows Firewall on or off.
Select On.
Click OK.

Connection Firewall in Windows XP

Click Start-> Control Panel.
Click Network and Internet Connections.

If you do not see Network and Internet Connections, click Switch to Category View.

Click Change Windows Firewall Settings.
Select On.
Click OK.
Update your computer

One can use Automatic Updates feature in Windows to automatically receive Microsoft security updates.

Windows Vista

Click Start-> Control Panel.
Click System and maintenance.
Select Install updates automatically
Select On.
Click OK.

Windows XP

Click Start, and click Control Panel.
Click System.
Click Automatic Updates.
Select Automatic

Source: iYogi