Re: Desktop Management

[Gary Flynn <flynngn () JMU EDU>]

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