Odd values/errors - need explanation

EvotecIT / Testimo

Testimo is a PowerShell module for running health checks for Active Directory against a bunch of different tests

MIT License

519 stars 55 forks source link

Odd values/errors - need explanation #144

Closed SUBnet192 closed 1 year ago

SUBnet192 commented 2 years ago

New domain in a lab, fresh install of 2022. The share permissions are all OK, but the "share permissions value" are all erroring out. what is that and why?

PrzemyslawKlys commented 2 years ago

You should use HTML information to find out what it shows. New domains have some discrepancies when it comes to built-in Administrators.

Or there is a bug but without more HTML output with details it's hard to say.

PrzemyslawKlys commented 2 years ago

You can run Invoke-GPOZaurr to see for yourself consistency of gpos for example will be broken. That Invoke-GPOZaurr -Type NetLogonPermissions should show you your problem too.

SUBnet192 commented 2 years ago

Invoke-GPOZaurr -Type Netlogonpermissions returns nothing.

SUBnet192 commented 2 years ago

The original error message indicates "expecting value Read, found value 2". I think the check is comparing the wrong values?

PrzemyslawKlys commented 2 years ago

Must be. I may have changed the output of the original cmdlet. Need to re-test it.

PrzemyslawKlys commented 2 years ago

What does this show: Get-ComputerSMBSharePermissions -ComputerName ad1 -ShareName Netlogon,Sysvol ?

That's for me

SUBnet192 commented 2 years ago

PrzemyslawKlys commented 2 years ago

That is so weird :/

SUBnet192 commented 2 years ago

I reapplied the default permissions to SYSVOL/Netlogon and all is fine now. Somehow one of the 2 BRAND NEW domain controllers in a BRAND NEW domain got borked... Oh well...

PrzemyslawKlys commented 2 years ago

Glad this got solved. That means the tool is working as expected ;-)

GertVanderstukken commented 1 year ago

Hmm,

I seem to have the same problem on a brand new Windows 2022 Domain Controller. Share permissions are correct, but it seems that the script is performing a count instead of a check towards the value in AccessRight.

When running the Powershell command as defined, I get the correct output:

Also, when I check the last printscreen from SUBnet192, I see that it is not checking against Read or Full anymore, but against a number???

PrzemyslawKlys commented 1 year ago

There is something wrong with this. I can replicate this but it shows up once every X number of times. I'll investigate.

PrzemyslawKlys commented 1 year ago

0.0.85 should fix this issue. I've reworked the cmdlet. The numbers were coming from Enums, and then we had some weird issue with Share command would return incomplete information. Hopefully now it's more bulletproof.

GertVanderstukken commented 1 year ago

Great.

I can confirm it's now working as expected. Thanks!!!