Did you know that Duke University has an AppleCare OS Support Select Agreement? We do! In addition to handling requests related to Apple OS, IOS and other products, Apple will work though this agreement to resolve issues related to Apple deployments managed via our Jamf Pro instance as well. A brief overview of the program details as well as the methods for getting tickets submitted can be found at the Duke Endpoints wiki.
IT workers fill a number of roles every day: user, admin, super-admin, and sometimes investigator. Each of these roles has different responsibilities and requires different rights on the systems involved. In order to practice good security and adhere to the principle of “least rights”, each of these roles should really use a different account. Let’s take a look at each of these roles and why they should each have a unique identity:
At the end of the day, in spite of being “smarter than the average bear” regarding technology, the IT worker is also a “normal” user. They log on to a primary workstation (or two), check e-mail, and message colleagues the same as anyone else. At Duke, this is done with what’s called a “person account”. This identity is the first that an employee is given at Duke and will follow them through their entire Duke career. Any other accounts an employee might have are considered “non-person accounts” and should either be tied to their person account or a Support Group of which they’re a member.
The User account is meant for doing personal work that affects only the account owner and their own device(s). Granting the User account additional (Admin) rights opens up the possibility that a personal action–intended to affect only the owner’s data or device(s)–has a wider effect than expected. An example of this would include searching for and deleting certain documents from a departmental directory on a file share only to find out that the action was done for the entire share and not just the one directory, inadvertently deleting files for other departments as well.
The User account is also the most frequently used and, as a consequence, the account most frequently compromised as a result of malware and phishing attacks. When an “elevated” User account is compromised, far more than the one individual’s data is potentially exposed.
Overall, it is much more secure to limit the User account to access only that which is necessary at an individual level.
As part of their responsibilities, almost all IT workers exercise some level of management over at least one other system that is used by at least one other person. Generally, this management is best performed via a tool of some sort. Patch management, software management, configuration management, etc., all have tools that can make the task much easier, whether it’s for managing one device or thousands. When operating at this level, the IT worker is no longer a “normal” user…they’re an administrative user, or “Admin”.
Access to actions performed on multiple devices used by multiple users should be limited to an Admin account. User accounts should not be granted the necessary rights to perform such actions.
Many IT workers–those without responsibility to directly manage other users’ devices or the tools that do so–will only need this one additional account.
For all of the management tools mentioned above, someone needs to manage the tools themselves. Through the management of these tools, some IT workers have access to much more than just the devices for which they are responsible; they have access to everything. This is not to imply that they’re responsible for everything, but that they have to be very careful when using these tools lest they affect far more than they intended.
Management of these tools should be limited to a Super-Admin account. Generally, management of such a tool involves either configuration changes to the tool itself (requiring no access to managed devices) or the development and testing of content to be deployed by the tool (requiring access to only a few test devices). To prevent events like the accidental distribution of software or settings to every device in the infrastructure, the Super-Admin account should–while having greater access to the tool than other Admin accounts–have lesser access to devices managed by the tool.
It can also be very useful for those Super-Admins without direct device management responsibilities to have an additional limited Admin account in order to see the system and its options as other Admins do. In addition, some systems may be important or sensitive enough that they should have their own individual credentials for access, requiring some IT workers to have multiple Super-Admin accounts.
Many IT workers–primarily those providing end-user support–are called to log on to systems that aren’t their own and/or are in an unknown state. When logging on to an end-user’s computer, it’s generally because there’s something wrong, possibly due to some form of malware. Just as “analog” investigators often wear gloves, goggles, or other gear to protect themselves from harm, having a separate account for logging on to devices in an unknown state can protect your other accounts from being exposed to malware on the unknown device.
As an alternative to an individual account, an Investigator account could also be a shared local administrator account. In addition to protecting the IT workers other accounts, the use of a local account also protects network resources that a network account would also have access to. Ideally, such an account would have a password that is unique to the device and changes on a regular basis via Microsoft’s LAPS or a similar solution.
So, how many accounts do you have? Chances are that, if you’re an IT worker at Duke and fulfill more than one of the roles mentioned above, the answer you gave is one or two accounts fewer than it should be. If this is the case, members of a Support Group can request a new “non-person” accounts at the Duke Sponsored Accounts page:
- Under “Non-person Accounts”, select the “Sponsor a Test or Service account” option.
- If you are a member of multiple Support Groups, you will be required to select one of these groups to be the initial Owner of this account. (If necessary, you can later change the owner to yourself for accounts that are for only your own use.)
- Under “Select Account Type”, select “Test” for accounts that will be used in the fashion mentioned above. “Service” accounts are generally not used in this way.
- Under “Select Non-person Account Preferences”, enter the appropriate information for this account. While you can be somewhat creative with the “First Name”, you’ll probably want to use your own “Last Name” to help with recognition.
- Under “Select Non-person Account Services”, select “NetID” and provide a NetID for the new account. This will ensure that you can use this account with just about any campus system (particularly those requiring MFA).
- Also under “Select Non-person Account Services”, if personal network storage will also be required for this account, select “CIFS” as well.
- When all that is complete, select “Submit” and your request will be on its way!
If your new Non-person Account will require MFA (which it should, but that’s another article), you’ll need to take a few extra steps:
- Go to the Duke Multi-Factor Authentication page.
- To enable MFA for a Non-person Account using a device:
- Under “View Devices”, select the appropriate device.
- Add the Non-person Account to the field under “Advanced users”.
- Select “Continue” to save your changes.
- To enable MFA for a Non-person Account using a Yubikey:
- Under “Manage Devices” –> “Advanced options”, select your token.
- Add the Non-person Account to the field under “Update your hardware token”.
- Select “Submit” to save your changes.
The Hard Part
Unfortunately, creating the extra account(s) is the easy part. Now, it’s up to you to make sure the services you interact with are configured to use the proper accounts in the proper way. However, the added protection you’ll have by doing so is worth it in the long run for both yourself and for all of Duke. If you have any questions or difficulty with figuring out this part (which could be different for each service), please don’t hesitate to ask the Endpoint Management community for assistance by joining and sending a message to firstname.lastname@example.org.
Effective use of Windows 10 Enterprise LTSB will depend on your specific needs and the needs of your users.
With the release of Windows 10 in 2015, Microsoft introduced a new sub-edition of Windows 10 Enterprise called “Long Term Servicing Branch” or “LTSB”. Each release of Windows 10 Enterprise LTSB will remain relatively unchanged–receiving only security updates and bug fixes, but no feature updates–through a 10-year lifespan.
To date, Microsoft has delivered two releases of Windows 10 Enterprise LTSB (2015 and 2016) with the next expected in 2019. While, according to Microsoft, LTSB was “designed for special-purpose PCs such as those used in point-of-sale systems or controlling factory or medical equipment”, some in IT have deployed it to common end-user computers, citing the benefit of having no Windows Store apps (which includes Microsoft Edge and Cortana) and no semi-annual feature updates to deal with.
However, recent articles and an updated Microsoft FAQ point out that, as released versions of Windows 10 Enterprise LTSB will not receive newer features, they will also not be supported on newer computer processors (such as Intel’s eighth-generation “Kaby Lake Refresh” architecture, released in August, 2017) . This introduces a potential down-side to deploying LTSB, but it’s not a new concept, as both Windows 7 and Windows 8.1, both still fully supported by Microsoft on older hardware, are only partially supported on Intel’s sixth-generation “Skylake” processors and are not supported on the seventh-generation “Kaby Lake” processors.
So, should we be deploying Windows 10 Enterprise LTSB here at Duke? That’s a question each group will have to answer for themselves. There are no security reasons to not deploy LTSB. There are no system management reasons to not deploy LTSB. There are only functionality and hardware requirements to be considered, and those requirements will be different from department to department and, in some cases, from user to user.
You should not deploy Windows 10 Enterprise 2016 LTSB if…
- …the user requires Windows Store apps (which includes Microsoft Edge and Cortana).
- …the user requires core Windows 10 functionality that’s been introduced since the latest LTSB release (Windows Subsystem for Linux, for example).
- …the user has a new computer running on an Intel eighth-generation “Kaby Lake Refresh” or newer processor.
- …your environment requires that all computers be running the exact same operating system.
You might want to consider deploying Windows 10 Enterprise 2016 LTSB if…
- …none of the previously stated requirements apply to your users or your environment.
- …you would like to completely opt out of Microsoft’s “Windows as a service” twice-per-year feature upgrade cycle.
- …you would like to opt out of the optional Windows Store software pre-loaded onto other Windows 10 editions.
- …you can support having multiple editions of Windows 10 in production on newer hardware.
With Windows 10 Enterprise 2016 LTSB, Microsoft provides a more stable and business-like environment, but at the expense of cutting-edge functionality and compatibility. Whether or not LTSB is right for you and your users is for you to decide. For some (like the author), the benefits outweigh the cost.
If you are part of the School of Medicine, School of Nursing, or are connected to the Duke Health System Network, you will need to install the BigFix client that communicates with the Health System instance of BigFix, not the Self-Managed Endpoint Client installers available through the OIT Software Licensing website. You can find the proper installers on the Duke Health Intranet BigFix page. Windows, Macintosh, and Linux clients are available along with instructions.
The purpose of Duke’s endpoint security program is to secure laptops and desktops purchased by Duke and used by faculty and staff. The applications used to support this efforts may only be used to: (a) report on missing software updates; or (b) apply missing software updates if the machine is fully managed by departmental or central IT staff. It will also be used to report and automatically address security issues on the machine such as the presence of viruses or malware.
Any IT administrators with access to the endpoint security tools, including the IT Security Office, are required to adhere to the Duke Acceptable Use Policy, particularly those statements regarding the expectation of privacy for the Duke community:
Duke cherishes freedom of expression, the diversity of values and perspectives inherent in an academic institution, the right to acknowledgment, and the value of privacy for all members of the Duke community. At the same time, Duke may be required by law to access and disclose information from computer and network users’ accounts or may find it necessary do so in order to protect Duke’s legal interests, uphold contractual obligations, or comply with other applicable Duke policies. Duke may also be required to access information to diagnose and correct technical problems.
IT administrators may not use their access to look at content on the systems they maintain, except for the conditions outlined above. Any additional access must be approved by the President or Executive Vice President of Duke University. Use of the security management tools is audited for this reason. Any concerns regarding inappropriate access should be directed to the school’s IT Director or campus IT Security Office.
In addition the departmental IT groups, IT administrators for the endpoint security software, and IT Security Office are bound by confidentiality agreements to keep any system information reported by the tools private. A copy of the confidentiality agreement may be found on Duke HR’s website.
This information is also available on the Duke IT Security Office website.
Due to of the risks posed by devices that are missing security updates, the University has implemented a policy that requires all Duke-owned endpoints (laptops, desktops, and Windows/Linux tablets) to be enrolled in a campus security management system by September 30, 2017. This policy applies not only to endpoint devices that are managed by a departmental IT support group, but also to Duke-owned devices that are managed by their primary user.
Endpoint Management software configured for self-managed endpoint devices is now available from the Duke Software Licensing site. Users with Windows or Linux devices should download the appropriate IBM BigFix client; users with macOS devices should download either the IBM BigFix client or the Jamf Casper client for that platform.
Note: If you are part of the School of Medicine, School of Nursing, or are connected to the Duke Health System Network, you will need to install the BigFix client that communicates with the Health System instance of BigFix. You can find these client installers on the Duke Health Intranet BigFix page. Windows, Macintosh, and Linux clients are available along with instructions.
Due to the risks posed by systems that are missing security updates, the University is implementing a policy that requires all Duke-owned computers to be enrolled in a campus security management system by Sept. 30, 2017.
This policy is designed to provide the University with the direction and support needed to ensure that devices connecting to our network are kept up-to-date with security patches and can be associated with an individual or group. While the methods may differ depending on the device type, the intent is to make sure all devices are well-protected.
Below is additional guidance for IT staff on implementation priorities:
- Planisphere: Use Planisphere for tracking your IT assets and identifying which are enrolled in one of the endpoint management tools. A new report shows the status of machines on a per-VRF and per-subnet basis. We’re still tweaking the report and adding more data sources for context. However, you should be able to pick the subnet or VRF you are interested in and get a list of what is connecting that needs to be addressed. As your Planisphere Support Groups are created, you will need to assign tags to filter your devices in Planisphere. We’ll be running informational sessions on Planisphere in the coming weeks to help you get started and to collect feedback. We’ll also be discussing Planisphere at various user group meetings, including SLG (early August), win-admin and unixgroup. In the meantime, please send feedback to email@example.com.
- Servers and VMs: Servers are considered to be different from laptops/desktops, but they should still be managed. OIT and other departments have made good use of SCCM, BigFix, WSUS, Puppet, Ansible, and Spacewalk as options. VM’s should also be maintained. VM’s running on enterprise infrastructure like ESX should be managed or tracked, and a process should be in place to track and/or update them. For VM’s on desktops and laptops, the priority is to ensure the host OS is kept up-to-date and tracked. Dual boot machines should have coverage on both OS’s, and will be reported in Planisphere.
- Research labs: If you have research lab environments, Duke OIT and ITSO would like to know about them so we can work with you on which alternative protections might be needed. Please email firstname.lastname@example.org for assistance with labs.
- Mobile devices: Phones and tablets are not in the policy’s current scope, but, if you have Duke-purchased phones and tablets, please begin considering how these are managed and tracked. Casper is available for iOS devices today, with information available on this site.