LAPS

Microsoft LAPS deployment and configuration guide

If you haven’t come across the term “LAPS” before, you might wonder what it is. The acronym stands for the “Local Administrator Password Solution.” The idea behind LAPS is that it allows for a piece of software to generate a password for the local administrator and then store that password in plain text in an Active Directory (AD) attribute.

Storing passwords in plain text may sound counter to all good security practices, but because LAPS using Active Directory permissions, those passwords can only be seen by users that have been given the rights to see them or those in a group with rights to see them.

The main use case here shows that you can freely give out the local admin password to someone who is travelling and might have problems logging in using cached account credentials. You can then have LAPS request a new password the next time they want to talk to an on-site AD over a VPN.

The tool is also useful for applications that have an auto login capability. The recently released Windows Admin Center is a great example of this:

LAPS

To set up LAPS, there are a few things you will need to do to get it working properly.

  1. Download the LAPS MSI file
  2. Schema change
  3. Install the LAPS Group Policy files
  4. Assign permissions to groups
  5. Install the LAPS DLL

Download LAPS

LAPS comes as an MSI file, which you’ll need to download and install onto a client machine, you can download it from Microsoft.

Schema change

LAPS needs to add two attributes to Active Directory, the administrator password and the expiration time. Changing the schema requires the LAPS PowerShell component to be installed. When done, launch PowerShell and run the commands:

Import-module AdmPwd.PS

Update-AdmPwdADSchema

You need to run these commands while logged in to the network as a schema admin.

Install the LAPS group policy files

The group policy needs to be installed onto your AD servers. The *.admx file goes into the “windows\policydefintions” folder and the *.adml file goes into “\windows\policydefinitions\[language]”

LAPS 02

Once installed, you should see a LAPS section in GPMC under Computer configuration -> Policies -> Administrative Templates -> LAPS

LAPS 03

The four options are as follows:

Password settings — This lets you set the complexity of the password and how often it is required to be changed.

Name of administrator account to manage — This is only required if you rename the administrator to something else. If you do not rename the local administrator, then leave it as “not configured.”

Do not allow password expiration time longer than required by policy — On some occasions (e.g. if the machine is remote), the device may not be on the network when the password expiration time is up. In those cases, LAPS will wait to change the password. If you set this to FALSE, then the password will be changed regardless of it can talk to AD or not.

Enable local password management — Turns on the group policy (GPO) and allows the computer to push the password into Active Directory.

The only option that needs to be altered from “not configured” is the “Enable local admin password management,” which enables the LAPS policy. Without this setting, you can deploy a LAPS GPO to a client machine and it will not work.

Assign permissions to groups

Now that the schema has been extended, the LAPS group policy needs to be configured and permissions need to be allocated. The way I do this is to setup an organizational until (OU), where computers will get the LAPS policy and a read-only group and a read/write group.

Because LAPS is a push process, (i.e. because the LAPS client on the computer is the one to set the password and push it to AD) the computer’s SELF object in AD needs to have permission to write to AD.

The PowerShell command to allow this to happen is:

Set-AdmPwdComputerSelfPermission -OrgUnit <name of the OU to delegate permissions>

To allow helpdesk admins to read LAPS set passwords, we need to allow a group to have that permission. I always setup a “LAPS Password Readers” group in AD, as it makes future administration easier. I do that with this line of PowerShell:

Set-AdmPwdReadPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>

The last group I set up is a “LAPS Admins” group. This group can tell LAPS to reset a password the next time that computer connects to AD. This is also set by PowerShell and the command to set it is:

Set-AdmPwdResetPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>

LAPS 04

Once the necessary permissions have been set up, you can move computers into the LAPS enabled OU and install the LAPS DLL onto those machines.

LAPS DLL

Now that the OU and permissions have been set up, the admpwd.dll file needs to be installed onto all the machines in the OU that have the LAPS GPO assigned to it. There are two ways of doing this. First, you can simply select the admpwd dll extension from the LAPS MSI file.

LAPS 05

Or, you can copy the DLL (admpwd.dll) to a location on the path, such as “%windir%\system32”, and then issue a regsvr32.exe AdmPwd.dll command. This process can also be included into a GPO start-up script or a golden image for future deployments.

Now that the DLL has been installed on the client, a gpupdate /force should allow the locally installed DLL to do its job and push the password into AD for future retrieval.

Retrieving passwords is straight forward. If the user in question has at least the LAPS read permission, they can use the LAPS GUI to retrieve the password.

The LAPS GUI can be installed by running the setup process and ensuring that “Fat Client UI” is selected. Once installed, it can be run just by launching the “LAPS UI.” Once launched, just enter the name of the computer you want the local admin password for and, if the permissions are set up correctly, you will see the password displayed.

LAPS 06

If you do not, check that that the GPO is being applied and that the permissions are set for the OU where the user account is configured.

Troubleshooting

Like anything, LAPS can cause a few quirks. The two most common quirks I see include when staff with permissions cannot view passwords and client machines do not update the password as required.

The first thing to check is that the admpwd.dll file is installed and registered. Then, check that the GPO is applying to the server that you’re trying to change the local admin password on with the command gpresult /r. I always like to give applications like LAPS their own GPO to make this sort of troubleshooting much easier.

Next, check that the GPO is actually turned on. One of the oddities of LAPS is that it is perfectly possible to set everything in the GPO and assign the GPO to an OU, but it will not do anything unless the “Enable Local password management” option is enabled.

If there are still problems, double check that the permissions that have been assigned. LAPS won’t error out, but the LAPS GUI will just show a blank for the password, which could mean that either the password has not been set or that the permissions have not been set correctly.

You can double check permissions using the extended attribute section of windows permissions. You can access this by launching Active Directory users and computers -> Browse to the computer object -> Properties -> Security -> Advanced

LAPS 07

Double click on the security principal:

LAPS 08

Scroll down and check that both Read ms-Mcs-AdmPwd and Write ms-Mcs-admpwd are ticked.

In summary, LAPS works very well and it is a great tool for deployment to servers, especially laptops and the like. It can be a little tricky to get working, but it is certainly worth the time investment.

Incident Response

6 Steps to Build an Incident Response Plan

According to the Identity Theft Research Center, 2017 saw 1,579 data breaches—a record high, and an almost 45 percent increase from the previous year. Like many IT service providers, you’re probably getting desensitized to statistics like this. But you still have to face facts: organizations will experience a security incident sooner or later. What’s important is that you are prepared so that the impact doesn’t harm your customers or disrupt their business.

Although, there’s a new element that organizations—both large and small—have to worry about: the “what.” What will happen when I get hacked? What information will be stolen or exposed? What will the consequences look like?

While definitive answers to these questions are tough to pin down, the best way to survive a data breach is to preemptively build and implement an incident response plan. An incident response plan is a detailed document that helps organizations respond to and recover from potential—and, in some cases, inevitable—security incidents. As small- and medium-sized businesses turn to managed services providers (MSPs) like you for protection and guidance, use these six steps to build a solid incident response plan to ensure your clients can handle a breach quickly, efficiently, and with minimal damage.

Step 1: Prepare

The first phase of building an incident response plan is to define, analyze, identify, and prepare. How will your client define a security incident? For example, is an attempted attack an incident, or does the attacker need to be successful to warrant response? Next, analyze the company’s IT environment and determine which system components, services, and applications are the most critical to maintaining operations in the event of the incident you’ve defined. Similarly, identify what essential data will need to be protected in the event of an incident. What data exists and where is it stored? What’s its value, both to the business and to a potential intruder? When you understand the various layers and nuances of importance to your client’s IT systems, you will be better suited to prepare a templatized response plan so that data can be quickly recovered.

Treat the preparation phase as a risk assessment. Be realistic about the potential weak points within the client’s systems; any component that has the potential for failure needs to be addressed. By performing this assessment early on, you’ll ensure these systems are maintained and protected, and be able to allocate the necessary resources for response, both staff and equipment—which brings us to our next step.

Step 2: Build a Response Team

Now it’s time to assemble a response team—a group of specialists within your and/or your clients’ business. This team comprises the key people who will work to mitigate the immediate issues concerning a data breach, protecting the elements you’ve identified in step one, and responding to any consequences that spiral out of such an incident.

As an MSP, one of your key functions will sit between the technical aspects of incident resolution and communication between other partners. In an effort to be the virtual CISO (vCISO) for your clients’ businesses, you’ll likely play the role of Incident Response Manager who will oversee and coordinate the response from a technical and procedural perspective.

Pro Tip: For a list of internal and external members needed on a client’s incident response team, check out this in-depth guide.

Step 3: Outline Response Requirements and Resolution Times

From the team you assembled in step two, each member will play a role in detecting, responding, mitigating damage, and resolving the incident within a set time frame. These response and resolution times may vary depending on the type of incident and its level of severity. Regardless, you’ll want to establish these time frames up front to ensure everyone is on the same page.

Ask your clients: “What will we need to contain a breach in the short term and long term? How long can you afford to be out of commission?” The answers to these questions will help you outline the specific requirements and time frame required to respond to and resolve a security incident.

If you want to take this a step further, you can create quick response guides that outline the team’s required actions and associated response times. Document what steps need to be taken to correct the damage and to restore your clients’ systems to full operation in a timely manner. If you choose to provide these guides, we suggest printing them out for your clients in case of a complete network or systems failure.

Step 4: Establish a Disaster Recovery Strategy

When all else fails, you need a plan for disaster recovery. This is the process of restoring and returning affected systems, devices, and data back onto your client’s business environment.

A reliable backup and disaster recovery (BDR) solution can help maximize your clients’ chances of surviving a breach by enabling frequent backups and recovery processes to mitigate data loss and future damage. Planning for disaster recovery in an incident response plan can ensure a quick and optimal recovery point, while allowing you to troubleshoot issues and prevent them from occurring again. Not every security incident will lead to a disaster recovery scenario, but it’s certainly a good idea to have a BDR solution in place if it’s needed.

Step 5: Run a Fire Drill

Once you’ve completed these first four steps of building an incident response plan, it’s vital that you test it. Put your team through a practice “fire drill.” When your drill (or incident) kicks off, your communications tree should go into effect, starting with notifying the PR, legal, executive leadership, and other teams that there is an incident in play. As it progresses, the incident response manager will make periodic reports to the entire group of stakeholders to establish how you will notify your customers, regulators, partners, and law enforcement, if necessary. Remember that, depending on the client’s industry, notifying the authorities and/or forensics activities may be a legal requirement. It’s important that the response team takes this seriously, because it will help you identify what works and which areas need improvement to optimize your plan for a real scenario.

Step 6: Plan for Debriefing

Lastly, you should come full circle with a debriefing. During a real security incident, this step should focus on dealing with the aftermath and identifying areas for continuous improvement. Take is this opportunity for your team to tackle items such as filling out an incident report, completing a gap analysis with the full team,  and keeping tabs on post-incident activity.

No company wants to go through a data breach, but it’s essential to plan for one. With these six steps, you and your clients will be well-equipped to face disaster, handle it when it happens, and learn all that you can to adapt for the future.


This article was provided by our service partner : Webroot

Active Directory

Three Active Directory Automation Scripting Tips Using PowerShell

Active Directory is one of the most common products I see being automated. After all, it’s the perfect candidate. How many times do new users have to be created, group memberships changed, or new computers added? Employees are coming and going all the time, and the actions to perform these tasks are the same—every time.

Microsoft® has an Active Directory (AD) PowerShell module that allows anyone to manage AD objects and write scripts to tie various tasks together. However, with PowerShell expertise, we can create scripts that go past just finding users and groups. We can automate any task you can think of in AD.

Find All Effective Members of a Group

AD has a great feature that allows you to add groups to other groups. This cuts down on the number of repeated group assignments you have to make, and makes AD much cleaner. However, when navigating to a group in the AD Graphical User Interface (GUI), you can only see the members in that immediate group. You may see others, but you’ll have to look at the members of those groups over and over again.

It can become a pain when you want to see all of the affected user accounts, but we can solve that using a PowerShell code and a recursive function.

To find members of a group with PowerShell, use the Get-AdGroupMember cmdlet. This command returns all members in just that group. However, a property on each of those members is an AD attribute indicating if it’s a user, a group, etc. That way, we know what kind of object it is. Knowing this, we can build code to look at each of those members, check to see if they’re a group, and if so, run Get-AdGroupMember again. If not, we return the member.

We need to use a recursive function—a function that calls itself, forcing it to find user accounts nested deep inside of various groups. By using a recursive function like this, a user can be nested ten groups deep, and we’ll still find it.

An example of how this can be done is below. This function can be called via Get-NestedGroupMember -Group MyGroup.

function Get-NestedGroupMember {
[CmdletBinding()]
param (
[Parameter(Mandatory)]
[string]$Group
)

## Find all members in the group specified
$members = Get-ADGroupMember -Identity $Group
foreach ($member in $members) {
## If any member in that group is another group just call this function again
if ($member.objectClass -eq 'group') {
Get-NestedGroupMember -Group $member.Name
} else { ## otherwise, just output the non-group object (probably a user account)
$member.Name
}
}
}
Easily Find Inactive Group Policy Objects

The next tip is finding inactive Group Policy Objects (GPOs). Especially in large organizations, GPOs can get out of hand and run wild unless controlled. Sometimes there ends up being dozens of GPOs created that aren’t doing anything at all. Rather than picking these out one at a time via the GUI, we can build a simple script to find them all in one shot.

There are two ways to define an inactive GPO. This GPO could have all of its settings disabled, or it could not be linked to an organizational unit. We can create a script to find both of these types. First, we’ll pull all of the GPOs in the environment:

$allGpos = Get-Gpo -All

Once we have them all, we can then filter those GPOs by the ones that have all settings disabled:

$disabledGpos = $allGpos | Where-Object { $_.GpoStatus -eq 'AllSettingsDisabled' }
foreach ($oGpo in $disabledGpos) {
[pscustomobject]@{
Name = $oGpo.DisplayName
Status = 'Disabled'
}
}

Next, we can find all GPOs that aren’t linked to an organizational unit. This is a little trickier, but nothing we can’t handle using the code below:

## Create an empty array
$unlinkedGpos = @()
foreach ($oGpo in $allGpos) {
## Gather up all settings in the GPO
[xml]$oGpoReport = Get-GPOReport -Guid $oGpo.ID -ReportType xml;
## Only return the GPOs that don't have a LinksTo property meaning they aren't linked to an OU
if ('LinksTo' -notin $oGpoReport.GPO.PSObject.Properties.Name) {
[pscustomobject]@{
Name = $oGpo.DisplayName
Status = 'Unlinked'
}
}
}

This script will return a list of GPOs that look like this:

Name Status
---- ------
GPO1 Unlinked
GPO2 Disabled
GPO3 Disabled
Find How Long Ago a User Reset Their Password

For my last tip, let’s figure out how long ago a user’s password was set. More specifically, let’s write a small script that will allow us to find only those users that have had their password set within a configurable amount of days.

This small script uses the Get-AdUser command and filters the users returned using the Where-Object command. In this example, we’re looking at the passwordlastset attribute for each user that is greater than 30 days ago.

$daysOld = 30
$today = Get-Date
Get-AdUser -Filter { enabled -eq $true } -Properties passwordlastset | Where-Object 
{ $_.passwordlastset -gt $today.AddDays(-$daysOld) }
Summary

We’ve just skimmed the surface on what’s possible when automating with PowerShell and Active Directory. By leveraging Microsoft’s Active Directory module and stringing together commands with PowerShell, we’re able to come up with some interesting scripts.

HIPAA

HIPAA Compliance — It’s the law…

As an IT Managed Services provider, we’ve heard it all…. I mean, who wants to take on another initiative that is as ambiguous and costly as HIPAA Compliance. Besides, your staff don’t have the time to take on more roles and responsibilities.

There’s only one problem though. These rules and regulations are signed into Law. That means, you are breaking the law. So, where does that leave us? Well, there’s 2 options: 1) Roll the dice and hope you don’t get audited/fined when PHI info is lost/stolen 2) Have someone like NetCal help you be compliant quickly and easily.

You see, we are forced to understand/implement the compliance requirements because as a Business Associate, we are also liable for our client’s non-compliance. We’re in this together and we got your back. It’s actually not as bad as everyone thinks. In particular, we know which items are important to focus on and we know how to get your business in compliance via best practices, trainings, templates, etc…

NetCal will perform the following tasks for you:

1. Perform HIPAA, MACRA, and Meaningful Use Risk Assessment
2. Write your Policies and Procedures
3. Train your Employees
4. Maintain your documents in a web portal
5. Provide support in the event of an audit

High-level Summary of Tasks Needed

1. BAA signings
2. User Training
3. Risk Assessment
4. Create HIPAA Policies
5. Perform IT Discovery and Vulnerabilities list
6. Create Recommendation and Security Plan

Major sites still largely lax on prompting users towards safer password choices, study finds

A study assessed whether or not the most popular English-language websites help users strengthen their security by providing them with guidance on creating safer passwords during account sign-up or password-change processes.

Some of the Internet’s biggest names largely fall short of nudging users towards safer choices when they create or change their passwords, a study by the University of Plymouth has found.

Steven Furnell, Professor of Information Security at the United Kingdom-based university, recently conducted an examination of the password practices of Google, Facebook, Wikipedia, Reddit, Yahoo, Amazon, Twitter, Instagram, Microsoft Live, and Netflix. The results – summed up in a paper called Assessing website password practices – over a decade of progress? – actually follow up on previous runs of the same survey in 2007, 2011, and 2014.

So what are the results? In short, some of the world’s biggest online services “still allow people to use the word ‘password’, while others will allow single-character passwords and basic words including a person’s surname or a repeat of their user identity”.

In other words, although there have been modest improvements on some scores, the picture has remained largely unchanged over the years, according to the survey. That is notwithstanding the increased threat of cyberattacks and privacy breaches, along with the fact that countless people continue to make one of the most common security mistakes by picking atrocious passwords.

On a positive note, the number of wildly popular sites in English that allow you to use “password” as your, well, password has dropped over the years. Also, the number of services that enable you to add an extra safeguard on top of your password by supporting two-factor authentication (2FA) has increased from three to eight between 2011 and 2018.

Enforcement of password restrictions and availability of additional support (source: Assessing website password practices – over a decade of progress? via TechCrunch)

Of the ten online services under review (although their composition has not remained unchanged over the years), Google, Microsoft Live, and Yahoo were found to provide the best assistance to users in designing a strong password. This holds true both for the survey’s 2014 and 2018 editions.

On the flip side, Amazon fared the worst, both now and four years ago, having been joined by Reddit and Wikipedia as the worst performers in the study’s latest run.

Now, in the absence of clear and thorough guidance on some of the biggest websites themselves, be sure to read our pieces on how to avoid the perils of passwords, their reuse, and, indeed, how to ditch your password and use a passphrase instead.

In addition, we’ve also reported on The Digital Identity Guidelines, drafted by the US National Institute for Standards and Technology (NIST) last year, which among other things recommend that every password should be compared against a “black list” of unacceptable passwords. Such a “wall of shame” should include predictable and easily guessable passwords, passwords leaked in past breaches, dictionary words, and common phrases that users are known to pick.


This article was provided by our service partner : Eset