trimarcjake / locksmith Goto Github PK

We need a methodology for ranking risk. This should be in place before we surface risk ratings to the user.

You cannot call a method on a null-valued expression.
At C:\Users\Administrator.xxx\Desktop\Invoke-Locksmith.ps1:336 char:13

•         $Issue | Add-Member -MemberType NoteProperty -Name Forest ...
  

•         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [], RuntimeException
  • FullyQualifiedErrorId : InvokeMethodOnNull

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/set-strictmode?view=powershell-7.2

ESC4 and ESC5 should report issues based on effective access instead of just filtering out Deny ACEs. Filtering Denys cuts down on false positives but doesn't provide a picture of true risk.

To be clear, risky Allows should still be removed when a corresponding Deny exists, but the actual risk presented is less than an Allow without a superseding Deny.

This appears to be a leftover from a previous PR that "moved" the Restricted Admin Mode check to the beginning of the script. I forgot to remove it here:
https://github.com/TrimarcJake/Locksmith/blob/2d54c5b1171f4a8c392e0b21a3a00eb7dd258149/Public/Invoke-Locksmith.ps1#L163C7-L163C7

    if (!$Credential -and (Get-RestrictedAdminModeSetting)) {
        Write-Warning "Restricted Admin Mode appears to be in place, re-run with the '-Credential domain\user' option"
        break;
    }

Description: Locksmith is alerting on safe objects.

Example: CN=Machine,CN=Certificate Templates... has the following set of rights:

ActiveDirectoryRights : ReadProperty, WriteProperty, ExtendedRight
InheritanceType       : None
ObjectType            : 0e10c968-78fb-11d2-90d4-00c04f79dc55
InheritedObjectType   : 00000000-0000-0000-0000-000000000000
ObjectFlags           : ObjectAceTypePresent
AccessControlType     : Allow
IdentityReference     : MARVEL\Domain Computers
IsInherited           : False
InheritanceFlags      : None
PropagationFlags      : None

This is safe because WriteProperty only applies to the 0e10c968-78fb-11d2-90d4-00c04f79dc55 (Enroll) right.

Expected Result: No alert on this template.

Actual Result: Locksmith marks this as ESC4.

Proposed Solution: ESC4 check should filter out anything to do with ObjectType 0e10c968-78fb-11d2-90d4-00c04f79dc55 (Enroll) and a05b8cc2-17bc-4802-a710-e7c15ab866a2 (AutoEnroll)

Special thanks to Thomas Andresen for bringing this to my attention!

I just encountered an error during SID translation in the Find-ESC4 function, and I haven't yet figured out what is causing it. This is probably related to something in my environment because we have not encountered these errors before, but I want to log it and figure it out.

[ADMIN]: D:\Files>.\Invoke-Locksmith.ps1 -Forest REDACTED
Gathering AD CS Objects from REDACTED...
Identifying auditing issues...
Identifying AD CS templates with dangerous configurations...
Identifying AD CS template and other objects with poor access control...
Exception calling "Translate" with "1" argument(s): "Some or all identity references could not be translated."
At D:\Files\Invoke-Locksmith.ps1:454 char:13
+             $SID = ($Principal.Translate([System.Security.Principal.S ...
+             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : IdentityNotMappedException

I looked a few lines above this and tried running $Principal = New-Object System.Security.Principal.NTAccount($_.nTSecurityDescriptor.Owner) and this also resulted in an error:

New-Object : A constructor was not found. Cannot find an appropriate constructor for type System.Security.Principal.NTAccount.
At line:1 char:14
+ ... Principal = New-Object System.Security.Principal.NTAccount($_.nTSecur ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [New-Object], PSArgumentException
    + FullyQualifiedErrorId : CannotFindAppropriateCtor,Microsoft.PowerShell.Commands.NewObjectCommand

For some reason it is failing to get the security principal of the current user and then failing to get the SID of the user. I do want to figure out why, but as an experiment I tried this code to get the SID, and it worked:

Add-Type -AssemblyName System.DirectoryServices.AccountManagement            
$SID = ([System.DirectoryServices.AccountManagement.UserPrincipal]::Current).SID.Value 

Systems Tested:

• Windows Server 2016
• Windows Server 2019
• PowerShell 5.1
• PowerShell 7.3.2

Privileges Used:

• Runas Admin
• Domain Admin

Will add more notes as I have time to reproduce and test. Additional thoughts are welcomed!

When a clearly unsafe group (Everyone, Authenticated Users, Domain Users, Domain Computers) owns a PKS object, Locksmith reports it twice.

msPKI-Certificate-Name-Flag check in ESC1-3 currently uses a direct comparison (-eq) instead of a bitwise comparison (-band) which could result in false negatives in situations where multiple msPKI-Certificate-Name-Flag bits are enabled.

If RSAT is not installed, Locksmith will silently install it if the user has admin rights. Instead, Locksmith should prompt the user for confirmation before installing and Import the AD PS module before continuing.

[ ] Add Confirmation dialog
[ ] Import module automatically.

Hi,

It seems that ESC8 identification is not accurate.
In my case I can confirm web enrollment is not installed and Windows authentication for CEP and CES is set to: Negoriate:Kerberos and Extended Protection is Required.
Still, running Locksmith comes up with "HTTP enrollment is enabled."

Current text colors work fine on dark terminal backgrounds but not so well on light backgrounds.

We're using AD Connect to replicate on-prem AD to Azure AD, which uses a service account (e.g. MSOL_db365a3ec62) to enumerate all of the AD objects to be replicated. This service account apparently has read/write access to all objects in AD, and so the Locksmith app reports it as ESC5-type misconfiguration on the AD CS computer object (see below). But doesnt this account require read/write access (or at least read) on the object to effectively replicate it to Azure AD?

What I expected would happen:

• Halting would allow continue of the fixes - i.e. just skip the one fix and move to the next one

What actually happened:

• Halting caused the script to terminate after pressing enter

Sample output:

Confirm
Continue with this operation?
[Y] Yes  [A] Yes to All  [H] Halt Command  [S] Suspend  [?] Help (default is "Y"): H
SKIPPED!
Press enter to continue...:

Running your excellent tool on non-english Active Directory environments trigger warnings for groups otherwise suppressed by the "SafeGroups", "SafeUsers" exclusions in your script.

For instance in German installations "Domain Admins" are named "Domänen-Admins" ...

(I had the same issue with Adalanche, and changing the queries to Well Known SIDs solved it.)

I'll test it, but I'd love to see what the tool will give me in the readme