PXE protocol details
Just did a quick PXE troubleshooting this week and I thought to share some good PXE document that explains the logic built into the protocol:
http://www.pix.net/software/pxeboot/archive/pxespec.pdf
It’s really old stuff, but it still helps to get an insight into the protocol. Also some stuff from Broadcom was also very helpful:
https://knowledge.broadcom.com/external/article/181525/using-a-wireshark-network-trace-to-troub.html
PS: Be careful with options 66/67 in DHCP; those are legacy and some vendors are ignoring it
About NT SERVICE\ALL SERVICES group
So what is with this group? I saw it on fresh OS install, GPOs, some random forum discussion. But not a lot explained on the MS docs. There is something but it’s kind of useless and confusing:
It says
S-1-5-80-0
All Services
A group that includes all service processes configured on the system. Membership is controlled by the operating system.
So it’s a well known SID/Group that is controlled by the OS. But the explanation is confusing. Actually it’s a group that contains all the virtual service accounts defined on the system, plus the managed service accounts(MSA), plus the group managed service accounts (GMSA).
This is very important for MSA and GMSA. You don’t need to grant the account Logon As a Service right, because on a fresh install of Windows 11, All Services group already has that right:
In case you use some domain GPOs and maybe those are inherited from some legacy systems, be careful not to overwrite this with some other values and remove it. Virtual accounts might not work anymore and you’ll have to grant rights individually for managed accounts.
More about on how Network Location Awareness Works
Because on some recent issues I had with NLA I’ve started to dig a bit on this subject and since there isn’t a lot of information about NLA available I though to share some of my findings:
– For everyone having issues with Domain detection please apply this workaround
– The domain profile isn’t set just based on the discovery of the domain (LDAP ping or DNS records). It requires Kerberos mutual authentication. So in order for NLA to set the domain profile, it needs the whole network stack to be initialized and fully operational.
– There is a security KB mentioning the update of NLA to use Kerberos authentication: https://docs.microsoft.com/en-us/security-updates/securitybulletins/2015/ms15-005
– If your computer account is out of sync, or deleted/reset, NLA will fail to set the Domain profile and you will end up in Private/Public. Check your Kerberos errors.
– Set-NetConnectionProfile can’t be used to set the Domain profile. The documentation is confusing.
– For the other profiles Private/Public, detection is based on the MAC address of the gateway device and stored in the registry in this location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged
Everything will probably be in this unmanaged section. Managed are the ones you preset via GPO.
Windows Server SMB Authentication Rate Limiter
A small but cool feature is available in the new insider version of Windows Server (soon to be available on Windows 11 too) called SMB Authentication Rate Limiter. This will slow down NTLM brute force attacks against SMB servers and will be a good protection for those small environments where advanced analytics and monitoring are not in place.
By default a delay of 2 seconds will be added between each failed NTLM logon and can be disabled or fine tuned to your desire (10 seconds maximum).
Configuration is done via Powershell using Set-SmbServerConfiguration:
Set-SmbServerConfiguration -InvalidAuthenticationDelayTimeInMs n
More details here:
https://aka.ms/smbauthratelimiter
Network Location Awareness (NLA) issues on Windows Server 2019
Lately I have encountered an issue where NLA wrongly identifies the network location as Public instead of Domain. This triggers the Windows Firewall to use the Public profile and from here an avalanche of issues.
What I have observed was that this happened on computers with a teamed network adapter that was also used to connect to the domain network. I think that maybe because of the delay added of the initialization of the network team, the NLA fails to contact a domain controller at the service start. When this happens the network location is set to Public. Restarting the NlaSvs service restores normal operation and the network location changes to Domain.
The only fix I have found to work was this registry key posted on the internet by a MS employee:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters
Add a DWORD parameter :AlwaysExpectDomainController
Set value to:1
Note: This registry key alters the behavior when NLA retries domain detection.
It seems that this tells NLA to retry the domain controller detection. And it seems to work. The other workarounds posted on the internet like delay start of NLA service or creating service dependencies were not reliable fixes.
The strange thing is that this registry setting doesn’t appear in any of the official MS documentation.
SMB security stuff
Just leaving here a couple of SMB security related stuff for anyone interested:
How to Defend Users from Interception Attacks via SMB Client Defense
Beyond the Edge: How to Secure SMB Traffic in Windows
Always use SMB signing (and encryption if possible; on SMBv3 it’s better to use encryption).
Do not be afraid to test and use the Microsoft Security Baselines.
Best Active Directory Docs Collection
If you’re looking for Active Directory documentation here’s a concentrated shot:
Time to return
Cautand ceva prin vechile mele postari am realizat ca au trecut fix doi ani de cand nu am mai postat nimic.
Si dupa tot ce am vazut in ultimii ani incep sa realizez din ce in ce mai mult ca lumea inca are nevoie de sysadmini. Asa ca o sa incep sa mai scriu din cand in cand chestii ce mi se par interesante.
PS: Zonele mele de expertiza nu s-au schimbat. In continuare sunt specializat pe migrari de Active Directory, asa ca daca aveti intrebari nu ezitati sa ma contactati.
Extract the filename from a path in Powershell
Lucrul cu string-uri e dificil cateodata iar unul din task-urile intalnite recent a fost sa extrag numele unui fisier dintr-un path.
De exemplu se da urmatorul string “C:\Data\reports1.csv”. Si task-ul este de a obtine numai numele fisierului din acest string. Bineinteles ca se poate face impartind tot stringul pe baza caracterului \ si citind doar ultima valoare. Dar spre norocul nostru, exista o comanda in Powershell ce face asta nativ si anume Split-Path.
Mai sus am pus cateva exemple. Pentru a obtine doar numele fisierului din path trebuie folosit parametrul –Leaf, altfel comanda va afisa doar path-ul, fara numele fisierului.
Pentru mai multe detalli precum si alte scenarii de utilizare a comenzii Split-Path aveti mai jos link-ul catre documentatie:
Vmware Workstation Shared Folders issue & Windows 10
Seems like after every Windows 10 upgrade, the shared folders inside Vmware Workstation VMs stop working. Reinstalling Vmware Tools and rebooting the VM or host will not fix this issue.
The problem seem to be related to this registry key:HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\ProviderOrder
The value should contain also vmhgfs and seems to be rewritten after each Windows 10 upgrade. So just add this value and shared folders should start working again (no reboot necessary).
Hope this will help other people experiencing this annoying issue.