User access policies for non-employees

Providing access for non-employees is a challenge in many regards. In this blog, IT pro Rick Vanover brings up some of the issues associated with this practice.

IT shops of any size have vendors, contractors or other people that may need some amount of access to systems on their network. There are a number of ways to manage the user account process of this need, and I’m out to see what TechRepublic members do to in this regard. Here are a few practices that I’ve come across:

Username identification: Some organizations make usernames like in Windows Active Directory and other systems across the board to identify the company in the systems.

Enable on-demand: User accounts for non-employees would be disabled by default, and only enabled when access is needed.

Time limited account: Accounts would be created, but valid only for a fixed duration of time. This makes the validity of the account re-affirmed periodically or it will safely go into a disabled state if there is no follow-up from the user or requestor of the access. This is frequently done with contract employees or temps.

Escorted access: This can be where an employee has to escort the non-employee in all systems. This can be managing a WebEx session and passing control or literally sitting over the shoulder of the vendor or other individual.

Permission lockdown: This is where the accounts are provisioned explicitly with what is needed for the requested access.

Isolated networks or domains: In the case of Active Directory, a child domain can exist with user accounts of this class for larger networks. For larger environments, this may make large-scale permissions tasks easier.

These are just a few of the strategies that can be employed, and organizations may elect a combination of this and other practices to fit the requirements for access and parameters of security. Please share the ways you address access for non-employees.