Educause Security Discussion mailing list archives
Re: Desktop Management
From: Gary Flynn <flynngn () JMU EDU>
Date: Wed, 1 Oct 2008 10:34:25 -0400
Andy Rivers wrote:
Good Morning, I was wondering what everyone is using to manage their workstations. We currently have several pilot projects going to evaluate different products and technologies, and I was curious how everyone else is managing their desktops. We are primarily interested in how administrative workstations are handled, not necessarily how labs are managed. Here are a few specific areas that we are wondering about: - Is Active Directory the primary choice for managing Windows clients? If so, how widely deployed is it? All workstations? Also, how strict of a policy are you applying?
We are in the final stages of a pilot desktop management program and are beginning to roll out to administrative departments. The IT department was the pilot group. We are planning to roll out to academic departments too. As support capabilities are ramped up, we should be able to demonstrate real benefits and a proven track record as we continue to roll out. The underlying integration technology is Active Directory domain membership. On top of that, we're using SMS, WSUS, and BeyondTrust Privilege Manager. Policies are "light", consisting mostly of firewall, WSUS, windows event log, and IE settings. We're using SMS to push non-Microsoft security defect patches ( e.g. products like Adobe Reader and Flash, Apple QuickTime, Java, and RealPlayer ) and make other software available. Several small areas of campus have converted to using non-administrative local logins over the past year or two. The domain migration process creates a domain account with the same privileges ( i.e. administrative or user ) as the existing local account. The plan is to migrate the domain accounts created as administrator accounts to regular user accounts at a later date after the domain membership allows inventorying software that may cause problems and remote support capabilities.
- How are policies and other activities managed in AD? All centrally? Delegate OU administration?
Our desktop services group manages most of them. We have a few departments and one college with delegated permissions. One college runs a completely separate domain. Designated "workstation administrators", support staff responsible for particular areas, have their domain accounts added to the local administrator's group on the computers for which they are responsible.
- What, if anything, are you using to push policy to OS X and Linux clients?
Nothing yet. That is phase two that we have not even started planning for.
- Has anyone tested or currently using products like Centrify and Likewise?
No. Our identity management web self service portal is used to change passwords for domain and other accounts. Its locally written. We're migrating to Oracle Identity Management but will likely have to keep a custom self-service portal.
Any advice or comments would be greatly appreciated.
If you're not presently doing central desktop configuration management, you'll almost certainly need to increase staff in your desktop services group. The payoff will come later. System administration and scripting experience would help immensely but they must be extremely cognizant of the difference between a host and desktop environment. The support model will change significantly from reactive to proactive. The reactive portions will be aided significantly by remote control, remote scripting, central configuration inventory and management but those tools need to be learned. If you move from using administrative accounts to regular user accounts, you'll have a significant initial support and user learning curve. Not insurmountable if you plan for it though. We purchased BeyondTrust Privilege Manager to help with this. Think about change management processes and roles early in the cycle. When you're making changes affecting thousands of desktops, mistakes or abuse can be painful. Be conservative and cautious. A new program does not need a black eye. We used the IPSEC firewall bypass functionality and windows firewall to restrict access to desktop management ports ( netbios, rpc, rdp ) on the desktops to a single system running terminal server through which all administrative staff must work. I've heard horror stories of domain accounts being compromised and used with impunity across a network without such a control. Think about your migration steps. For the past year or so, every new computer that gets imaged by our desktop services folks has been joined to the domain even if the department had not yet been migrated in mass. Such computers are put in a "holding OU" where no policies are applied. When the department is migrated, the computers are already in the domain can simply be moved to the departmental OU. Consider the effect of migrating a computer with encryption technology like EFS enabled into a domain. Computer and account SID and password changes can get you into trouble if you haven't thought it out previously. Consider your sales pitch. The major benefits are not visible to the average person. Remote support is probably one of the few. The user will see changes that don't immediately benefit them and that is always a problem. The program must be sold on another level. Explain the problems you're trying to solve, the threats you're facing, and the risks of not addressing them. Explain the functionality, integration, and support benefits that will result when fully deployed. Do it in plain language. Upper management must be brought in early and support the program. Fear of change and the unknown is your enemy. Communicate clearly and often. Don't use words like "control", "force", "restrict", and "prohibit" in your documentation or presentations. I like to think if the right support resources and infrastructure are in place, all we're doing is taking the drudgery, complexity, and risk off the shoulders of the end user and providing new ways to deliver service and react quickly to changes in the environment. Make them your partners. Escalate any support calls in the newly migrated environment expeditiously. Do not confuse desktop management with policy concerning use of administrative vs user accounts. They are separate issues. The migration to a managed, supportable desktop environment is aided by the migration to use of user accounts and the desktop management infrastructure aids that migration. They're closely interlinked but still different. Remember the 80/20 rule. Don't get caught up in dogma, politics, and stubbornness. Its better to make exceptions and compromises than to derail the entire program. Be flexible in the interest of getting the primary services deployed. 1500 managed desktops and 200 unmanaged ones is better than no managed desktops. Over time, the benefits and your competencies should prove themselves. Address real risks in your policies. Don't squabble over whether a screen saver timeout should be 30 minutes or 60 minutes and not be able to push critical security patches because of it. -- Gary Flynn Security Engineer James Madison University www.jmu.edu/computing/security
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Current thread:
- Desktop Management Andy Rivers (Oct 01)
- <Possible follow-ups>
- Re: Desktop Management Derek Ethier (Oct 01)
- Re: Desktop Management Gary Flynn (Oct 01)
- Re: Desktop Management Rob Whalen (Oct 06)
- Re: Desktop Management Derek Ethier (Oct 06)