The MDT Deployment Database is a great utility for your Deployments, no matter if you are using it in LTI or ZTI scenarios. Tim Mintner recently wrote an interesting article about what the Database is and why one should use it. If you use the Deployment console to access the database it has (at least) one major drawback, especially in larger Deployments. Out of the box, the console is the only way of accessing and changing the database (beside using the SQL Management Studio and making changes directly to the underlying tables.). But due to it’s “All or Nothing” approach, you have to give everyone who needs to be able to make changes to the database full access to all information. But you might want to restrict, what people are able to see and change. You might want to give the Helpdesk guys only access to the computer information. Or might want to restrict a local Site Administrator to the settings of the site(s) he/she is managing.

This particular problem was one of the main reasons for the development of the MDT Web FrontEnd. It is a web-based FrontEnd, giving you easy and customizable access to the MDT Deployment Database and will work without any changes to the original tables. After the installation (see the Installation Guide for more information) it will behave like the original Deployment console and give everyone who can access the website access to all settings. But it has a built-in security model you can use by extending the original MDT Deployment Database (see Extending the database for more details). It just adds a couple of tables and stored procedures to the database without any changes to the original ones. So it will still be 100% compatible if you use the console to access the database. In this How-To I will now show you the concept on how the security model has been designed and how you can use these features to give your users and colleagues the access they need to do their job, without giving them the possibility to harm anything they shouldn’t even touch.

OK, let’s start.

The Security Concept

Access Roles

The idea is to map the requirements of a specific access scenario into an “Access Role”. Each Access Role defines the access to either one specific type of Identities (Computer, MakeModel, Role or Location), or to all of them. Each Identity Type has certain areas like the Details, Settings, Packages, Administrators, etc. The Access Role now defines the Access Level for each of this different areas. The Access Level is quite simple. It’s either Read-Only, Full Access or no Access at all.

Sounds a bit confusing? No problem. Let’s have a look on an example. We assume we have a couple of Users sitting in the Helpdesk. They regularly prepare new computers or schedule re-images on existing computers. So they shall be able to change some settings for the computer like the Computername, be able to add and remove predefined Roles, add or remove packages to the computer which shall be installed or add local Administrators in case a specific User needs to be a local Administrator. But they shall not be able to access anything besides Computers. So we open the Web FrontEnd and click on the “Admin” Tab and then on the “Access Roles” Tab to see a list of all existing Access Roles. After the installation there will be two pre-defined Access Roles “Default Access All” which will give every User Full Access to everything. That mimics the usage of the console. Looking at the below screenshot you can see the security settings for each Access Role and also a column called “Default”. Default Access Roles will apply to every User who can access the website at all. Typically you have either one Default Access Role for all identities. Or you have one per Identity you want to give access to. Even if possible, you shouldn't`t create several Default Roles for the same Identity. So the first thing you might want to do after a fresh installation of the FrontEnd is creating a new “Default” Access Role which fits to your needs. A “ReadOnly Example” that gives only Read access has also been supplied in the installation.

OK, we click on the “Add Access Role” Button. In the following screen we can now create our new Access Role. We call it “Computer Editors” (Or Helpesk, or whatever suits your needs), as this Role gives Full Access to all Computers only. Also supply a meaningful Description. Now we set the “Type” to “Computer” and set all Access Levels to “Change” (The “Gateways” area makes only sense for an Identity Type of “Location” but that shouldn’t matter for now). We don’t want to  make it “Default”. The option “Groups” defines what you can see and change if you click on the Settings Tab of an Identity. But this will be part of an additional How-To. So for now select the Group “MDT 2008 Default” or “MDT 2010 Default” depending on if you are using MDT 2008 or MDT 2010. 

Then click on “Create” and the Access Role will have been added to the list of Access Roles.

Access Role Assignments

We have now defined a new Access Role that will give somebody access to all areas of the configuration of a computer. Now we need to configure, what users shall be using this Access Role. Users can have several Access Roles assigned. And one Access Role can be assigned to several Users. An Access Role can either apply for all instances of an Identity Type (e.g. All Computers), or just for specific instances (e.g. Location “A”, “W” and “Z”). Based on this, we have the full flexibility from Full Access for Everyone down to single instance for a specific User only. And everything in between. You could even give each of your Users access to the configuration of his/her computer(s). This would probably be an administrative nightmare to keep up to date, but it’s up to you how to use it (Maybe someone will create a small script handling this assignments during logon of each User ;-) ). But let’s assign our new Access Role to a couple of User from the Helpdesk. In the list of Access Roles you can see an icon for the “Assignments” ( ) . Click on this Icon and you will see the list of all Users this Access Role has been assigned to and for what Instances (Either “All” or the specific instances):

Now you can “Create a new Assignment” using a 2-Step wizard. In the first step, you need to choose the User(s) you want to assign to the Access Role.

the second Step is to choose the Instances this User/these Users shall be assigned to. It’s either “All” for all current and future Instances or any number of current instances. If you need to create different combinations of Users and Instances, you need to run this wizard several times. Click on “Finish” to apply these changes to the database and with immediate effect, the chosen user(s) will be able to access everything you defined before.

Users

As seen before, to be able to assign an Access Role, you need to choose from a list of Users. Users can be added to the database on two ways. First, each User accessing any page of the FrontEnd will be added to the Database for future usage. (if the database hasn’t been extended this will be ignored by the FrontEnd. And NO, currently there is no usage logging integrated). So fastest way might be to ask the User to access the FrontEnd and after that just add the user to all the Access Roles he/she requires. You also might want to add the First and Lastname later to make it easier to identify them later.

The second way is to manually add the User to the Database. To do this click on the “Admin” Tab and then on the “Users” Tab. You will see a list of all Users currently configured in the Database.

From here you can Add new users or Edit/Delete existing ones and even see all the assignments, a specific user has. The most important part to know here is, that the FrontEnd assumes Active Directory authentication and will try to map the “Username” to the Username supplied by the Browser. So use “Domain\Logonname” as the value in Username if you use Active Directory. If you use a different authentication method it still should work, but most probably requires some more configuration. Also this is untested.

Note: All the mentioned configuration can only be done by a User who has been configured as Administrator (All users that have the checkbox “IsAdmin” checked). If you have just set up the FrontEnd, there won’t be any user, so no one would be able to configure the database as there isn’t any Administrator yet. To overcome this issue, the first User accessing any page of the FrontEnd after it has been set up will become an Administrator. All others will still be added to the database, but just as normal users.

I hope this guide gave you some insight on how you could handle different security requirements of your Deployments. The example itself is quite simple but should show you how to set this up yourself. The main recommendation is to first configure your “Default” access, meaning create one (or several if you need different “Defaults” per identity) Default Access Role that configures what everyone who is able to access this FrontEnd shall be able to see and do. This may vary between No Access at all up to Read access to everything or even Full control on some parts. Then identify the different requirements you have. Mostly you can group your users depending on the required access levels. E.g. Helpdesk access to all computers, Site Administrators access to their locations, Role Administrators to manage all Roles, etc. If a User has been assigned to different Access Roles he/she will have the highest access level configured. Meaning “No Access” does not overwrite any other access level currently assigned.

If a user has more permissions effectively as he should have, there typically is a “default” Access Role giving this permission. So try to keep it as simple as possible, but as complex as necessary.

For more information please see Managing enhanced security features from the MDT Web FrontEnd Documentation. If you have any suggestions or feedback, don’t hesitate to write a comment here or on Codeplex, start a discussion or just contact me. The FrontEnd is currently still in Beta, but already very stable. The first Release will be published soon and it’s already used in production in several environment.

The next How To will cover the creation of the before mentioned “Groups”. A quite powerful feature giving you even more flexibility on what you want to show to the User.

The following How Tos have been published so far:

- How To restrict access to the Deployment Database

- How To configure what a User can see and edit

- How To handle Custom Settings

- How To create custom Lists to select pre-defined values for a setting

- How To handle MDT Applications in the FrontEnd

- How To handle SCCM packages