To find Specific GPO Settings are being applied, and which GPO is affecting which setting, you can generate an html report, there are two ways of doing this. You can either run the report on the affected machine, or if you do not have access, you can generate the same report on a domain controller (or any machine that has the group Policy Management console installed).
Solution: Find Specific GPO Settings (Locally)
On the machine in question run the following command (remember to be logged in with the credentials of an affected user!)
It will take a little while for the report to be generated but it ‘should’ open in you default browser, like so.
From here you can see a list of all the applied GPOs, and drill down into each setting, and see the ‘Wining GPO‘ that applied that setting.
Solution: Find Specific GPO Settings (Centrally)
Most people are unaware that you can do the same from any machine that’s running the Group Policy Management administrative tool, it has a section called group policy modelling. the reason this exists is to ‘try out’ the effect of changing groups, OUs and WMI filters to see how that affects the application of GPOs to both users and computers however, if you just plus in the computer name and the users name and accept all the defaults it will give you the SAME report you generated above.
From Administrative tools > Group policy management > Group Policy modelling > Group Policy modelling wizard > Next > Next (unless you want to change the DC queried).
Select the user and computer in question > Next > Next > Next.
Next > Next > Next.
Next > Next > Finish.
The report will be rendered on screen, with the same information as if you had run gpresult manually on the client.
Related Articles, References, Credits, or External Links
With Azure AD Replication, you may notice that you have the following error when you take a look at your connector status;
Error: permission-issue Connected data source error code: 8344 Connected data source error: Insufficient access rights to perform this operation.
Solution: Error Code 8344
Firstly ensure that the user you are running AAD sync under, has the following permissions on the ‘root’ of your local AD domain.
Replicating Directory Changes: Allow
Replicating Directory Changes All: Allow
If the problem persists it’s usually because the account that is running the AAD sync does not have the appropriate rights to the mS-DS-ConsitencyGuid attribute for the affected users in the local Active Directory. The following commands will add the appropriate rights you ALL your local users;
Lastly, if you have this problem on some ‘sporadic’ users, check to ensure that their individual user objects and inheritance enabled on their user object, before retrying.
If the problem persists use the AD Connect Troubleshooter.
Fix Error Code 8344 with AD Connect Troubleshooter
Open Azure AD Connect > Configure.
Troubleshoot > Next > Troubleshooting > Launch.
Option 4 > Note: At this point you may or may not be asked to install the RTSAT tools, if so enter Y {Enter} > Option 12 > Y {Enter} > E {Enter} > Type in the name of the connector (in the example below that’s pnl.com).
You will be prompted to authenticate with an administrative account > You will then have to accept each change, by typing A {Enter} You will need to do this SEVEN TIMES.
When complete force a full initial replication.
[box]
Start-ADSyncCycle -PolicyType Initial
[/box]
At this point go an have a cup of coffee, then come back and check Synchronisation Service Manager. You should now be error free.
Related Articles, References, Credits, or External Links
I needed to get a list of operating systems ‘in-use‘ in my active directory this week. bear in mind this will pull information from all enables computer accounts in AD, so if you are ‘not good‘ at tidying out old machines and servers you might get a lot of garbage in your output!
If you attempt to edit the authOrig attribute of a mail enabled group using ADSIedit you will get the following error.
There is no editor registered to handle this attribute type.
Why would you be doing this? This is done when you want to restrict who can email a group.
Solution
If you are running either on-premises Microsoft Exchange (or are running in Hybrid Exchange mode, and have retained an Exchange server for management,) You can simply use the Exchange Admin Center to add the person or group that you want to restrict access to.
Recipients > Groups > Group-Name > Edit > Delivery Management > Set accordingly.
Note: As I’m in Hybrid mode, and have AAD Sync setup, if I attempt to look at this group in O365 / Exchange online, it simply says.
You can only manage this group in your on premises environment. Use Active Directory users and groups, or Exchange AdminCenter tools to edit or delete this group.
Technical Pedantry: The fact it’s been called ‘Active Directory Users and Computers‘ since Windows 2000 makes my OCD flinch at that comment.
Use PowerShell
You can (if you have no access to Exchange Management tools) simply use PowerShell, the syntax is as follows.
[box]
Set-ADGroup -Identity "The-Group" -Server The-Domain-Controller -Add @{authOrig=@('The User or Group to Grand access to')}
e.g.
Set-ADGroup -Identity "CN=DG-Test-Disty-Group,CN=Users,DC=pnl,DC=com" -Server PNL-MGMT.pnl.com -Add @{authOrig=@('CN=Pete Long,CN=Users,DC=pnl,DC=com')}
[/box]
Then to prove it’s not all ‘smoke and mirrors’ you can go back to ADSIedit and check.
Related Articles, References, Credits, or External Links
I saw this asked on a forum this morning and, went to test the answer (and create an article if successful), to find out the posted answer and most of the info I found online was for Microsoft LAPSand not the newer Windows LAPS.
Let’s say we have an OU called Computers (with my computers in) and I want to grant read permissions to LAPS password to a security group called LAPS-Password-Admins.
The under the older, Microsoft LAPS system we would use the following PowerShell syntax.
Try that on a Widows LAPS deployment, and you will get the following error.
Set-AdmPwdReadPasswordPermission : The term ‘Set-AdmPwdReadPasswordPermission’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Because if you’re using Windows LAPS then that commandlet has been replaced, you need to use the following syntax instead.
I’ve been setting up a VPN solution on the test bench as I’m looking at Always On VPN. When I noticed that I had a problem with my remote VPN connections on Windows. They would connect fine but I could not resolve any FQDNs for my domain?
VPN no DNS Solution
By default, all (Windows) VPN connections are ‘Force Tunnel’ (this means they have the option ‘Use default gateway on remote network’ selected). This also means that, (unless your RAS server is the default Gateway for your network,) you usually don’t have internet access when connected to the VPN.
Now I connected fine, and I could ping IP addresses on my corporate network, but I could not ping my servers by their domain name, in fact Windows was trying to resolve my domain name to a public IP?
Google this problem and you’re simply told to ‘Disable IPv6 on your network card, and this works, (if you want to keep your remote users Force-Tunnelled). But disabling IPv6 is hardly a fix is it?
Also If you want internet access for your remote clients, (Commonly referred to as ‘Split Tunnel’), then even with IPv6 disabled, the problem comes back!
Why is this happening? Well even with Force Tunnel enabled, you can still use your local LAN (Connect to your VPN, and ping your home gateway, or printer or wireless access point if you don’t believe me!) This connection takes precedence over your remote VPN connection, to prove it run a netstat -rn command.
From the above you can see my Ethernet Adaptor has a metric of 6, and my VPN connector, (in this case called Connection Template) has metric of 23. AND THE LOWEST ONE WINS, so your DNS queries are going out of your local internet connection NOT down the VPN tunnel!
How Do I Fix this VPN no DNS?
Well until Microsoft fixes this in Windows 10, (it’s fine on Windows 8 and earlier), you have to manipulate the metrics yourself, like so;
VPN no DNS On Your Physical Adapter;
Start > ncpa.cpl {enter} > Right click your NIC > Properties > Internet Protocol Version 4 > Properties.
Advanced > Untick ‘Automatic Metric’ > Set the Interface Metric to 20 > OK > OK >OK.
On Your VPN Connector;
Start > ncpa.cpl {enter} > Right click your VPN Connector > Properties > Internet Protocol Version 4 > Properties.
Advanced > Untick ‘Automatic Metric’ > Set the Interface Metric to 10 > OK > OK >OK.
Now your DNS look-ups should behave!
Related Articles, References, Credits, or External Links
If you have a lot of user groups and simply want to copy/clone one users group membership to another user, then with PowerShell that’s quite simple to do.
Solution: Copy User Membership
Here I have two users ALane who is a member of a few groups and APatel who is simply a member of domain admins.
Although we can see above what groups ALane is a member off let’s prove that will PowerShell.
Way back when I started doing tech (in the days of Novell 4 and NT4), my mantra was, if you must deny something then you’ve done something wrong. Now I work for a UK based MSP that offers SPLA licensing to clients.
Unlike typical RDS licensing, With SPLA this requires every ‘capable‘ AD user that ‘can‘ RDP onto a server (regardless of it’s a Session Host RDS Server or not) needs to have an RDS SAL.
So, when audited and hit with a big licensing bill, the clients first question is usually “How do I reduce this?“
Solution: Deny RDS
Create a new security group (don’t use domain users!) Give it a sensible name i.e. GS-Deny-RDS-Access (GS for Global security, and I don’t like spaces in names, as it makes scripts easier to write!)
Obviously put in the users you want to explicitly deny RDS access to.
Create (or edit an existing) Group policy linked either to the OU that contains your servers (remember domain controllers are in a different OU, so link it there also). Or If you’re lazy like me simply link it to the root of the domain.
Edit the policy and navigate to.
[box]
Computer Configuration > Policies > Windows Settings > Security Settings > User Rights Assignment > Deny Log on through Remote Desktop Services
[/box]
Enable the policy > Browse to and select the group you created earlier.
It’s been a long time since I ran through setting up a central policy definitiosn store. In that time, you’ve probably had to copy ADMX (and ADML) files into your central store manually. Microsoft updates typically DO download updates but puts them (usually) in C:\Windows\PolicyDefinitions, There’s probably a sensible reason for that.
When someone cleverer than I has scripted this, and included support not just for Windows, but for;
Adobe Acrobat
Adobe Reader
Base Image Script Framework (BIS-F)
Citrix Workspace App
FSLogix
Google Chrome
Microsoft Desktop Optimization Pack
Microsoft Edge (Chromium)
Microsoft Office
Microsoft OneDrive (installed or Evergreen)
Microsoft Windows 10 (1903/1909/2004/20H2/21H1/21H2/22H2)
Microsoft Windows 11 (21H2/22H2)
Mozilla Firefox
Zoom Desktop Client
Solution: Auto Update ADMX
Execute the following command.
[box]
Install-Script -Name EvergreenADMX
[/box]
Answer any questions with a ‘Y’.
Now to test the script you can simply run Evergreenadmx.ps1 and it should run though manually. Once you’ve ascertained that it runs without error you can use the following syntax to update you central store*
Here I’m creating a Scheduled task (If you feeling lazy simply import this one) Give it a sensible name > I would set it to run monthly Unless you are downloading browser and application ADMX files also > I’ve scheduled it for the second Wednesday of the month (See what I did there?)
We used to have Microsoft LAPS, now we have Windows LAPS!LAPS is a solution that lets’ you store admin passwords ‘elsewhere‘ be that in your local Active Directory or Azure Active Directory*. Unlike previously, where you had to deploy/install client software, it’s now built into Windows from the following versions.
Windows 11 22H2 – April 11 2023 Update
Windows 11 21H2 – April 11 2023 Update
Windows 10 – April 11 2023 Update
Windows Server 2022 – April 11 2023 Update
Windows Server 2019 – April 11 2023 Update
*Note: Is in the pipeline at time of writing traditional (on-premises) AD only is supported.
The premise is that instead of having a single (easily compromised) local admin password (or DSRM password on a DC) for your assets you can have a different password (that can be controlled with a complexity policy) for each client/server and that password is stored securely in Active Directory, (as an attribute of the computer object).
Backup to Azure AD
Backup to Local (On-Premises) AD
Azure AD Joined
Yes
No
Local (On-Premises) Joined
No
Yes
Hybrid Joined
Yes (if not backed up to on-premises AD)
Yes (if not backed up to Azure AD)
Workplace Joined
No
No
Solution: Windows LAPS
Firstly, FULLY update all the domain controllers in the domain.
On a DC you can load the LAPS module and look at the commandlets.
[box]
ipmo LAPS
gcm -Module
[/box]
From these commandlets the first one we need to use is Update-LapsAdSchema, this will extend the active directory schema and add the LAPS attributes to the computer objects.
[box]
Update-LapsAdSchema
[/box]
It will ask you con conform you can watch each step by pressing Y – or if you’re lazy (like me) simply press A {Enter}.
You can’t really see what it is doing, but if you’re interested, you can run the same command again with a -verbose switch on it to see exactly what going on.
OK, but what has that done? Well as I said above, the computer objects have been extended and they now have ALL have the following attributes.
Note: Yes, there’s now a LAPS tab also, but there won’t be anything in there yet.
The next commandlet we need, Set-LapsADComputerSelfPermission, will grant the computer object the rights to manage its own LAPS password, You can set this on the root of the domain if you wish. Here I have all my computer objects in an OU called PNL so I’m applying that right at the TOP LEVEL OU, and it will apply to all children OUs.
Create a new GPO (or edit an existing one) that links to the OU where your COMPUTER objects live. (remember if managing DSRM passwords you will also need to link the policy to the Domain Controllers OU also).
Edit the Policy and navigate to;
[box]
Computer configuration > Policies > Administrative Templates > System > LAPS
[/box]
Note: If you have a LAPS folder directly under Administrative Templates, that’s for the older Microsoft LAPS settings!
Policies to edit;
Enable Password Backup for DSRM accounts : Enable
Name of administrator account to manage : Enable >laps.admin
Note: If you already have a local admin account, built into you master computer image for example, you can use that account instead.
Further policy to edit;
Password settings : Enable > (I accept the defaults)
The screen shot below shows how the policy should look before you exit the group policy editor.
Windows LAPS Local Admin
Here I’ve manually created the local user, you can either roll this out by script, GPO, or building the account into the your default image for OS deployment.
Retrieving Windows LAPS Passwords
Below you can see we can retrieve both a local Windows LAPS password for a client, or a DSRM password for a domain controller.
Simply click Show password and Copy password, and the password will be on the clipboard (as shown).
To get the password via PowerShell use the Get-LapsADPassword commandlet.
[box]
Get-LapsADPassword "PNL-Win11" -AsPlainText
[/box]
Troubleshooting Windows LAPS
The update also allows you to view LAPS event logs in the Event Viewer, like so.
Interoperability Microsoft LAPS and Window LAPS
If you have the older Microsoft LAPS running (i.e. Your end clients have the LAPS client software being deployed to them, then when the Apr 23 LAPS update is deployed to them and used, BOTH Systems may stop working. To fix this you need to disable Legacy LAPS by setting the following registry key on your clients.
[box]
HKLM > Software > Microsoft > Windows > CurrentVersion > LAPS > Config
[/box]
Create a new 32 bit DWORD value called BackupDirectory and set its value to 0 (zero).
Once the Azure AD element is fully released and supported, I’ll loop back and include that also.
Related Articles, References, Credits, or External Links
