Local Security Solution is a great tool. Included in its capabilities is the ability to manage and randomize passwords for local users, specifically the local Administrator account. This is great because it provides proper and secure access and password randomization to and for that data, for those that need to access the client machines.
One of the more difficult challenges has been to use a this solution, or for that matter, any other solution to access and manage client machines in a DMZ (de-militarized zone for the military buffs) - but for the purposes of this discussion it is a location where more publicly visible machines are safely connected, with limited access to the internal LAN and presenting a wore public face to the WAN or Internet.
Altiris Solutions and the management platform that they reside on work well to manage hosts in a DMZ. The easiest of all solutions is to manage them with a Notification Server (NS) in the DMZ proper. However, in smaller organizations, configuring and managing multiple Notification Servers may not be in design or budget, and a single NS can be configured to manage client machines in both network locations.
This article will focus on the basic configuration of LSS for DMZ clients and the resolution of some problems that have been encountered.
Please note that this articles function is not to provide explanation and usage details for all of the functionality of Local Security Solution, but rather applying the Local Administrator Password Management Tasks and Policies to client machines in a DMZ, and the internal network (LAN), and the advantages and limitations of tasks and policies. With this information, it is hoped that you will have a proper tool to plan your management of Local Administrator Passwords using Local Security Solution. A basic understanding of how Local Security Solution manages passwords is assumed.
Understanding the Different Password Management Methods (Task vs. Policy)
There are two different ways that Local Security Solution manages passwords.
- Tasks ( Using Task Server functionality)
- Policies
Having an understanding of these two methods will make choosing one easier in your environment.
Task-Based Password Management (Using Task Server)
Using Task Server to manage passwords is fairly simple. In Figure 1 below, you can see where (shown here using the Altiris 6.5 console - all tasks can be performed in either the 6.0 or 6.5 console) to right -click and select a new Task/Job
Figure 1
Your next choice is to choose which type of task you want to use. The "Randomize Local User Account Password" choice, shown in Figure 2, is Local Security Solution's implementation of password management using Task Server.
The options for this task are to provide a meaningful name and description for your implementation. You then choose the user account that this task will manage. Your two options here are either a standard account or a Named account. By selecting the "Standard" radio button, the dropdown provides the two standard choices:
You may choose any local named account that resides on the hosts that you are managing, by selecting the "Named" radio button, and providing the correct account name.
Next, you are offered a choice for "Password length". 14 is the default. Enter a value based on your corporate password policies.
Figure 2
The "Use characters" option lists the requirements for the password options you need. Again, configure this to your environments requirements.
Lastly, the "Log password at the server before change" sends a NSE file with the password prior to the change. Then Click OK.
You will then be presented with a screen as shown in Figure 3 below. Your next choices, as you read right above the title of the task, are to "Create Schedule", "Run Now" or to "Edit".
At this point it is important to know that you can create a recurring schedule with which to run this task, and that, based on that schedule, the passwords for the accounts you manage will be randomized.
Figure 3
Figure 4 below shows what the "Create Schedule" screen looks like. Provide a name for the schedule, and a description. The name of the task to be run has been filled out. You next need to select a shared or custom schedule, and if you choose custom, you will be required to provide the schedule details. Lastly, under the "Task Input" section, select either a collection of computers, or specific computer names to which the combination of the task and schedule will apply to.
Figure 4
Once completed, click "OK" and then Figure 5 shows what the combination of the schedule and task appear like in the console. This task will then run on the configured schedule.
Figure 5
Things to Watch For when Using Tasks for Password Management
Using the task method, while providing the password management functions needed, does NOT provide any easily usable client side logging or tracking, unless you configure client side log files to retain a large amount of data, such as trace level logging, over an extended period of time. The server-side tracking is found in the "Task Status" section of the screenshots, shown in Figures 3 and 4. You can use the Resource Manager for a managed resource and review the Events Tab. There should be an event for the "User Account Password Change" dataclass, which displays a policy guid of 35f3fe35-4f02-4576-965f-bd0106816a8e, which references to the Local User Inventory Policy. That is why task-based password management is difficult to track.
Figure 6
Also, exercise caution in the frequency of cleaning your task event history as they appear Figure 7. If you remove completed tasks on a frequent basis, you cannot track when or where the task succeeded or failed.
Figure 7
Also, if you rename the primary password management task itself to a naming convention that is not easily recognizable as a password randomization task, you may not later be able to edit or modify the task to accommodate new client machines or a schedule modification requirement, and makes troubleshooting very difficult.
If you have NOT configured any type of password management policy for a client machine, but have the LSS agents installed, you might see errors similar to this in the client log files:
Process: AeXNSAgent.exe (5348)
Thread ID: 5540
Module: AeXNetComms.dll
Source: SecureSocket
Description: Error -2147014842 sending close notify
Prior to that entry, the two following entries were also noticed:
Process: AeXNSAgent.exe (5348)
Thread ID: 4568
Module: AltirisLSSAgent.dll
Source: LocalSecurityAgent
Description: Setting wakeup time to 17000 ms (5/26/2009 9:20:37 AM)
Process: AeXNSAgent.exe (5348)
Thread ID: 4568
Module: AltirisLSSAgent.dll
Source: CLocalUserComputerInventory
Description: BuildPrivilegeMembership : Privilege SeUnsolicitedInputPrivilege does not exist
You will simply need to provide a password management task or policy to resolve the above problem. To assure that you can manage password tasks for client machines in a DMZ, you should make sure as well that Task Server is functioning in your DMZ. More than likely that will require your network administrator to open the following ports on the DMZ firewall device:
Task Server Ports
- TCP Port 50120 (Task Server Data Loader)
- TCP Port 50121 (Altiris HTTP Server connection to host )
- TCP Port 50122 (Altiris HTTP Server connection to host)
- TCP Port 50123 (Tickle Server)
Task Server Client Ports
- 50124 (To receive Tickle Packets)
Now that we have discussed how to build the task option above, let's review configuring a policy below.
Policy-Based Password Management
Creating a policy to provide random password management is very similar to using a task. The user-interface options are nearly the same. The 6.0 console is exhibited below in Figure 8, but the same policy creation can be performed in either version.
As you can see in Figure 8, when you browse to Security Management> Local User Tasks, you can see that a default policy exists for administrators, named "Random Password Policy For Administrators". This policy is explained further below.
Figure 8
To create a new policy, right -click on the folder you wish to store the policy in and select New> Local User Random Password Policy.
The "New Local User Random Password Policy" choice, shown in Figure 9 below, is Local Security Solution's implementation of policy-based password management.
The first options for this policy include providing a meaningful name and description for your policy, consistent with your corporate standards.
Next, select a previously defined computer collection. This is the primary difference in the configuration of the policy versus the task option. The task option requires selection of either scheduling the task, or an immediate "Run Now", to assign the task to resources, but the policy requires a collection definition to complete the policy configuration.
You then choose the user account that this task will manage. The two options here are, similar to the task option, either to provide a standard account or a Named account. By selecting the "Standard" radio button, the dropdown provides the two standard choices:
As with the task-based option, you may choose any local named account that resides on the hosts that you are managing, by selecting the "Named" radio button, and providing the correct account name.
Next, you are offered a choice for "Password length". 14 is the default. Again, enter a value based on your corporate password policies.
The "Use characters" option lists the requirements for the password options you need. Again, configure this to your environments requirements.
Lastly, the "Log password at the server before change" sends a NSE file with the password prior to the change. Then check the "Enable" box, and click Apply.
Figure 9
In addition to configuring your own policy, Figure 8 also displays a default policy. When you browse to Security Management> Local User Tasks, you can see that a default policy exists for administrators, named "Random Password Policy For Administrators". If this account is the only account you would like to manage on your client machines, then simply enable the policy. The applicable collection has been defined to accommodate those machines that do not have services configured to use the local Administrator account. Adjust the remainder of the settings to your choice, check the enable box, and click apply.
Things to Watch For when Using Policies for Password Management
Using policy-based management is the easier of the two methods for DMZ hosts. There are no open port requirements between network zones, and the ability to track policy function, using standard tools and reports is much easier.
To be assured that all of your client machines that are not currently password-managed receive the policy, the following SQL definition for a collection will make sure that they get included.
select u.AccountDomain as GUID from inv_global_account_details u
join inv_local_user_account_details d
on d._ResourceGuid=u._ResourceGuid
left outer join inv_user_account_password p
on p._ResourceGuid=d._ResourceGuid
where u.RID=500 and p.Password is null
This should enumerate all of the hosts that do not have their local administrator passwords managed to the policy, so that those passwords can be managed.