Skip to main content

Active Directory

Active Directory is a campus-wide authentication directory that supports enterprise systems, provides contact information and scheduling integration, along with providing mechanisms for centralized desktop management. The BYU campus Active Directory environment provides the following benefits:

  • Log in with standard BYU netid and password - one login to remember
  • Password synced between AD and other campus services (email, MyBYU, software.byu.edu, etc)
  • Reduce overhead through standardization
  • Central rights management - rights to campus resources are granted from a single location
  • Improved services through centralized management (mapped department and personal drives, automatic printer installation, workstation updating and patching, etc)
  • Improve workstation security - limit who can and can't login
  • Backed up data on departmental and personal drives
  • Lower departmental cost because infrastructure is managed and maintained by LSIT
AD Naming Conventions
AD Conventions
Faculty Admin Access
Importing
Installing AD
AD Security Structure
Resource Management
Faculty Computers
Restrict Groups
RIC Lab AD Add

**Note: This KB was originally edited via this top-level text editor available on this page, NOT on the second-level editor (the one that brings up a new dialog) that is available from the top-right pencil icon.

Edited by Kyle Harline 6/5/19

Administrative Accounts

What You'll Need

ItemNaming Convention
1 Group Policy ObjectLFSCI-Admin-[Name of User/Group/Lab]
1 Security GroupLFSCI-Admin-[Name of User/Group/Lab]
1 or more Domain User Accounts[NetID]-admin
1 or more Domain Computer Accounts[ROOM][BLDG][#]

Shared Network Printers

What You'll Need

ItemNaming Convention
1 Group Policy ObjectLFSCI-Print-[BLDG] [ROOM] ([Name of Printer])
1 Security GroupLFSCI-Print-[BLDG] [ROOM] ([Name of Printer]) Users

Shared Network Storage

What You'll Need

ItemNaming Convention
1 Group Policy ObjectLFSCI-Admin-[Name of User/Group/Lab] )
1 Security GroupLFSCI-Admin[Name of User/Group/Lab] )
1 or more Domain User Accounts[NetID]-admin
1 or more Domain Computer Accounts[ROOM][BLDG][#]

Software Installation

What You'll Need

ItemNaming Convention
1 Group Policy ObjectLFSCI-Admin-[Name of User/Group/Lab] )
1 Security GroupLFSCI-Admin[Name of User/Group/Lab] )
1 or more Domain User Accounts[NetID]-admin
1 or more Domain Computer Accounts[ROOM][BLDG][#]

Interactive Logon Access

What You'll Need

ItemNaming Convention
1 Group Policy ObjectLFSCI-Admin-[Name of User/Group/Lab] )
1 Security GroupLFSCI-Admin[Name of User/Group/Lab] )
1 or more Domain User Accounts[NetID]-admin
1 or more Domain Computer Accounts[ROOM][BLDG][#]

Network Access

What You'll Need

ItemNaming Convention
1 Group Policy ObjectLFSCI-Admin-[Name of User/Group/Lab] )
1 Security GroupLFSCI-Admin[Name of User/Group/Lab] )
1 or more Domain User Accounts[NetID]-admin
1 or more Domain Computer Accounts[ROOM][BLDG][#]

Remote Desktop Connection Access

What You'll Need

ItemNaming Convention
1 Group Policy ObjectLFSCI-Admin-[Name of User/Group/Lab] )
1 Security GroupLFSCI-Admin[Name of User/Group/Lab] )
1 or more Domain User Accounts[NetID]-admin
1 or more Domain Computer Accounts[ROOM][BLDG][#]

University Mandated Conventions

The Organizational Units (OU) for each college reside in the root of the BYU.LOCAL Active Directory. The name of each OU is also the designated prefix for that college in regards to naming conventions for Security Groups and Group Policy Objects. (NOTE: Organizational Units do not require a prefix since their names are resolved to fully-qualified names using parent containers. Prefixes are not required for User objects. However, User Objects are required to have a hyphen somewhere in the account name to avoid conflicts with Route Y user names.)

College Mandated Conventions

Organizational Units

Inside the college OU are the following sub-OUs:

  • CSR
  • Departments
  • Labs & Kiosks
  • Servers

Overview

This article is split into three parts:1) Our admin policy2) How to create an admin account3) How to add a computer to a list of computers for an existing admin account

Our policy

Before a faculty member gets access, they need to speak to Darin for approval. You can make the admin account after Darin gives the green light. When a faculty member logs in to your admin account on their computer, a link to a website should already be there on their desktop. This links them to the Administrator Changelog, which is where they are asked to log any changes they make with their admin account. This helps us track problems back to possible sources if issues arise in the future. We also need to explain to faculty that they are asked to not use their admin account for everyday work. They should use their normal account and only use their admin account when prompted for administrator credentials. This lowers the risk of malware and other threats to their computer and the BYU network.

Service Desk Starts Here:

Creating a new admin account

This describes what to do if a professor has never had an admin account before.

Create an admin user in Active Directory

  1. Open Active Directory and open up the faculty's folder. Move the computer into the folder.
  2. Right-click on white space (not in the explorer pane) and go to New > User.
  3. Put in their first name, then last name followed by Admin (ex. First name: Nathan, Last name: Stokes Admin). This just makes it clear that it's an admin account.
  4. Under "User logon name", type in their RouteY ID followed by "-admin" (ex. newman-admin). Click on Next.
  5. Assign them a password (something like "fall2016") and make sure the box "User must change password at next logon" is selected. Click Next. Click Finish.
  6. Right-click on white space again and go to New > Group.
  7. Under "Group name", put "LFSCI-Admin-Full Name" (ie. LFSCI-Admin-Nathan Stokes), including spaces. Click OK.

8. Add the new user to the new security group. You can do this by right-clicking on the new user and selecting "Add to a group...". Type in the full name of the new group and click "Check name" to make sure you typed it correctly, then add it.

9. Right-click on the new security group and select "Add to a group..." and add it to the group "LFSCI-Admin-Faculty Administrators". Check name, and add.

Service Desk can Pass it off to Engineering Here:

Create a policy in Group Policy Management

1. Open Group Policy Management and find the professor. Right click on their name and select “Create a GPO in this domain, and Link it here...". A box will appear asking you to name it. Call it "LFSCI-Admin-Full Name", (ex. LFSCI-Admin-Nathan Stokes), including spaces.

2. On the left, a new "LFSCI-Admin-Full Name" icon should have appeared under the faculty member's folder. Right-click on that and click on "Edit...". Double-click through this pathway: Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups. You should have arrived to an empty window.

3. Right-click on white space and click on New > Local Group (or click on the blue plus sign at the top to do the same thing).

4. Next to "Group name", type "Administrators". Don't hit "..." or click on the drop down menu to select "Administrators (built-in)". For whatever reason, having the (built-in) option selected makes it not work. Just type in "Administrators" and leave it at that.

5. At the bottom click on "Add..." and type "BYU\RouteYID-admin" (ex. BYU\jsmithjr-admin). Click OK, then click OK. Close that blue window to go back to normal Group Policy Management.

6. On the bottom half of Group Policy Management, under "Security Filtering", click on "Add...". Click on "Object Types..." and check the box for Computers. Type in the name of the computer the professor needs access to, click on Check Names to make sure it's fine, then click OK. They will only have admin privileges on computers that are specified for here.

7. At the top of that window, right under "LFSCI-Admin-Joseph Smith", there are four tabs. Click on the one that says "Delegation". At the bottom, click "Add..." and add "LFSCI-GPOManagers". This will allow any CSR to change their policy in the future, instead of just the user who made the policy. Click OK. When a new window appears, change the permissions to "Edit settings, delete, modify security" and then click OK.

8. Have the professor restart that computer. Have them log in to the admin account so they can reset the password. Don't forget to explain our administrator policy to them (see top).

Add computers for an existing admin account

These are basically repeat steps from the part just above this, but this serves as a quick reference on how to add additional computers for a professor that already has an admin account. If Danny has already allowed them admin access on another computer, then they can have admin access on any computer, so if a professor asks for admin access on another computer, you don't have to run it past Danny again.

1. Open Group Policy Management (Found in Administrator Tools in Control Panel) and find the professor.

2. On the bottom half of Group Policy Management, under "Security Filtering", click on "Add...". Click on "Object Types..." and check the box for Computers. Type in the name of the computer the professor needs access to, click on Check Names to make sure it's fine, then click OK. They will only have admin privileges on computers that are specified for here.

3. Have the professor restart that computer.

Viewing Changelogs made by Administrators

1. Visit lsit.byu.edu

2. Under the 'Services' tab there is a link that says 'Administrator Changelog.'

3. Sign in (this will enable you to access more links under the 'Services' tab.

4. This will take you to the administrator changelog form, so go back to 'Services' tab and click the 'Changelog listing' tab.

This will show changelogs submitted by faculty with administrator accounts.

Importing AD Information

Do the following to import AD info into google docs:

  1. Log on to a server on the domain ('lsadmig' for byu.local)
  2. Run 'cmd'
  3. In the command line run
    1. csvde -f updatedates.csv -r objectClass=Computer -L "cn, whenchanged, lastlogon, lastlogontimestamp"
    2. and save the resulting CSV to your L drive.
  4. On one of the CSR computers ('lscsr1', 'lscsr2', etc.) open up your L drive and make sure the CSV file is there
  5. In google docs, open up a new spreadsheet. Click File->Import. Browse to the CSV file
  6. Congratulations! I hope you can make sense of it.

Installing Active Directory (Remote Server Administration Tools)

Download and install the appropriate Remote Server Administration Tools for the version of OS being run.

Here is the Windows 10 page.

Download and install the appropriate Remote Server Administration Tools for the version of OS being run.

Here is the Windows 10 page

Supplemental Security Groups

The following groups are supplemental to the main office security structure outlined above. Membership to these groups (and consequently, access to the resources they represent) is granted indirectly through the groups main office security groups or directly on a case by case basis:

Security Group

LFSCI-Computer Managers:

  • Members of this group can move computer accounts from the 'Computers' default container, which is outside of the college's OU and therefore out of reach to college CSR employees not in this group.

LFSCI-GPO Managers:

  • Members of this group can create, modify, and delete group policy objects and link them to OUs within the college OU. NOTE: By default, when GPOs are created, only enterprise admins (OIT), domain admins (OIT) and the creator of the GPO have access to modify and delete it. It is therefore important when creating new GPOs, to give the LFSCI-GPOManagers group permission to modify and delete the GPO so that everyone that should have access has it.

LFSCI-UserProperties Managers:

  • Members of this group can change the value of the 'Home folder' attribute on the 'Profile' tab of the 'Properties' dialog for users in the 'People' OU.

LFSCI-College Resource Admins:

LFSCI-Logon-Terminal Services Users:

  • Members of this group have access to connect to computers in the college through Remote Desktop Connection (RDC).

LFSCI-Service-LS Chat Users:

  • Members of this group have access to login to the chat server hosted on lschat.byu.edu.

LFSCI-HP-Admin:

  • Member of this group have full access to the servers in the HP management tool (192.168.54.51)

LFSCI-HP-Cluster:

  • Member of this group have hardware access he the Cluster servers in the HP management tool (192.168.54.51)

LFSCI-HP-ESX:

  • Member of this group have hardware access he the ESX servers in the HP management tool (192.168.54.51)

LFSCI-VPN-Management:

  • Users in this group are granted access to the 192.168.54.x network through VPN.

LFSCI-VPN-Web:

  • Users in this group are granted access to the 192.168.51.x network through VPN

Adding AD to Faculty Computers

Download and install the appropriate Remote Server Administration Tools for the version of OS being run. Here is the Windows 10 page.

Introduction

This website was developed to simplify the management of Active Directory 'resources'. Active Directory resources are essentially Security Groups that have been given permissions for IT resources such as printers, server storage, administrator accounts, login access, etc. The website searches through the Active Directory for Security Groups that the logged-in user has rights to manage (meaning that the Security Group's 'manageBy' property is set to the user's account or a Security Group of which the user is a member). The application then lists these 'managed' Security Groups as Active Directory resources. After clicking on one of these 'resources', the user can then add and remove users from that 'resource'. This provides a very simple way for anyone (with the right permissions) to give users access to IT resources.

Functionality

The ultimate functionality and effect of the application is dependent upon the configuration of relevant security groups and group policy objects in the Active Directory. Ideally,Group Policy Objects are put in place to provide resources such as printers, network shares, logon access, administrative access, etc., to users and computers. Once these GPOs are in place, security groups can be created to limit the scope of application of the GPOs such that membership in the security group is required in order to have access to the given resource. Once the security groups are in place an additional security group can be created to manage each resource. The value of the 'Manage By' attribute of the original security groups can be set to the 'Manager' security group. When someone in the 'Manager' security group logs into the BYU-ADRM application, the application searches for all the groups of which that user is a member which are also 'Managers' of other groups. The resource groups are then displayed for the user to modify as necessary. Users can be added and removed as needed.

An Example of a Resource Configuration

Assume that 'LFSCI-CollegePrinter' is a GPO that connects a college printer to user accounts. 'LFSCI-CollegePrinterUsers' is a security group used to limit the application of the 'LFSCI-CollegePrinter' GPO; only members of the 'LFSCI-CollegePrinterUsers' group have the college printer connected to their account. An additional security group is created called 'LFSCI-CollegePrinterManagers'. The value of the 'LFSCI-CollegePrinterUsers' group's 'Manage By' attribute is set to 'LFSCI-CollegePrinterManagers'. Furthermore, the user with account ID of 'abc' is made a member of the 'LFSCI-CollegePrinterManagers' group. When the user 'abc' logs into the BYU-ADRM application, that user will see the 'LFSCI-CollegePrinterUsers' group and be able to add and remove users from that group, effectively granting and revoking access to the college printer.

Setting Up The BYU-ADRM Application

When a user first logs into the BYU-ADRM application, they are prompted for their user name and password. The application uses these credentials to impersonate the user in order to carry out tasks such as querying the Active Directory for groups and adding and removing users from groups. In order for this to work, IIS needs to be configured properly. The application is currently running on a Windows Server 2003 R2 Standard SP2 machine with IIS 6, although it has been tested on IIS 7 as well and works fine. After opening the IIS console and opening the Properties dialog for the application website (right-click the application node in the IIS console), select the 'Directory Security' tab and click 'Edit' under 'Authentication and access control'. Uncheck 'Enable anonymous access'. Uncheck all other checkboxes except 'Basic authentication'. In the textbox labeled 'Default domain' type the name of the domain against which the application should authenticate (In the case of the campus Active Directory, this should be 'byu.local'). Click 'OK', and then 'OK' again. The IIS server should now be configured.

Methodologies

During the implementation of the BYU Active Directory (byu.local) in the College of Life Sciences various Security Group configurations were tried to determine the best option for managing resources through ADRM. Initially, a very hierarchal approach was used which allowed for a very flexible and very complex management structure. Certain groups were created to represent resources; other groups were created to manage the managers of those resources; still other groups were created to administer the managers' groups. This structure quickly became too cumbersome and resulted in quirky behavior of the website (administrators ended up having access to groups that they could not directly remove themselves from without recursively adding themselves to groups through the structure until they got to the right level to remove themselves from the original resource). Also, granularity was used heavily in the beginning to provide more flexibility. Security Groups were created for every resource, and each resource was displayed on the website separately. In practice, however, we found that most administrators in the college gave access to groups of resources, not single resources. For example, an employee in charge of a group of secretaries would give each secretary access to log into the office computers, print to all of the printers, and access the server storage space all at once. With each of these resources managed separately, the administrator would have to add the Net IDs of each secretary separately to each resource.

Now, a single 'Office Resources' group is created for each administrator; that group is given access to each of the Security Groups representing the various resources that the office employees use. This means that, generally, the administrator will have only one resource to manage. Adding and removing users to/from this single 'Office Resource' group, adds and removes those users to/from all the individual resource groups (e.g. the printer resource group, the server storage resource group, etc).

Adding AD to Faculty Computers

Download and install the appropriate Remote Server Administration Tools for the version of OS being run.

Here is the Windows 10 page.

Creating Restrict Groups in AD

Steps

  1. In Active Directory, do the following:
    1. Create a Restrict Group in the Faculty's OU
    2. Add Users that need access
    3. Add Computers that need to be restricted
  2. In Group Policy Management, do the following:
    1. Create a new GPO with naming convention (LFSCI-Restrict-<Name>)
    2. Add the AD Group you created under the "Scope" Tab, on the "Security Filtering" list
    3. Change the settings (Settings Tab) to reflect the following hierarchy:
      1. Computer Configuration (Enabled)
        1. Policies
          1. Windows Settings
            1. Security Settings
              1. Local Policies/User Rights Assignment
                1. Policy: Allow log on locally
                2. Setting: LFSCI-IT, <YOUR AD GROUP HERE>, BUILTIN\Administrators
                3. (Without the LFSCI-IT and Administrators Group, we can't log into the computer!)
    4. Add LFSCI-IT to the "Delegation" tab
    5. Link this GPO to the Faculty's OU
  3. Done!

Typically when you add a student to an AD group you need an Email from the Professor to confirming that they want that student added. Dr. Sandra Hope has given authorization that her 3 RIC lab managers have the power to request AD adds to the RIC Lab student group. The Three managers are the following:

Charlie Roll

Cameron Arnold

Kevin Torgersen

Created: Scott Dayley 6/19/19

Updated: Scott Dayley 6/19/19