Well, i have to admit that the information in this post is so important to me as i always wanted to get data from standalone deployments. I hope that you will find it useful to you also.
Nowadays, with all security concerns and attacks, many application architectures contain standalone not domain joined roles. Take Microsoft Lync for example, they have a separate Edge role to handle media from external clients and for security reasons, this role is meant to be a standalone deployment and never joined to the internal domain.
Exchange Architecture also contains an Edge role acting as SMTP gateway and for security concerns this is a standalone role that is not joined to the internal corporate domain.
As a PowerShell guy, i always write scripts to collect data, report data, or even send SMTP alerts in case of failures. I usually have a dedicated VM that is acting as a script server that runs all my scripts. I always find it challenging to collect remote WMI data from those standalone not domain joined machines.
The challenge is : How a script running on my script server that is member of contoso domain, and running under contoso\user1 credentials, will be able to connect to that remote standalone server and get WMI data for example.
- Go to the standalone computer, create a local user called User1 with the same password as Contoso\User1 (which is the account im using to run scripts on the domain joined script server) , and i will add it to the local administrators group on the standalone server.
Now, i have domain user called contoso\User1 running my script on the script server with Password = 123 for example, and i have similar but local user on the standalone server called User1 with same Password=123 , and member of the local administrators group of the standalone server.
- On the standalone server, i have to enable something called (LocalAccountTokenFilterPolicy) to do the trick. This is saying that, if i receive a connection with a user name and password that matches a local user account on my local credential store, i will consider it valid transaction, and even if the matching local account is administrator, i will elevate the remote connection to a token with admin rights.
Data: 1 (to disable, 0 enables filtering)
Type: REG_DWORD (32-bit)
Enabling this registry key is somehow a balance between scrutiny and usability. Make sure you understand what you are giving by disabling this filter.
Read more about this registry key here http://support.microsoft.com/kb/942817