Windows gMSA Discovery Issues - Looking for ideas.

[Scott Braden]

Presently in our environment we have a gMSA account configured for the purposes of discovering Windows Devices. It has been up and operational for about a year and a half. Recently it was brought to my teams attention that there are a handful of windows servers functioning as Certificate Authorities which aren't being discovered using the gMSA account. 

When I try to test the gMSA account credential against the devices in question the credential fails. 

When I try a quick discovery against the devices the discovery fails and the error log tells me that the credential failed. 

The above leads me to believe we have a gMSA permissions issue.

I've engaged my Core Services Team and they've shown screen shots of the gMSA account confirming that it is in the proper groups to have Admin access over the boxes in question. 

To sort of double check things, I've logged into my Mid Servers and run: 

• tnc command to check if port 135 can indeed be communicated with.  

I also found a post from Doug Schulze dating back to 2010 https://www.servicenow.com/community/itom-forum/advanced-discovery-troubleshooting-wmi/m-p/1011689 where Doug outlines a method for proving the WMI Connection through Powershell/Command Prompt. 

My Issue with Dougs post and applying it to my situation is a gMSA Account technically can't be logged onto Interactively, I found a method of being able to do so using psexec patrickkeisler.com - How to Logon Interactively with a group managed service account . 

So I used the psexec method to run powershell to then run what Doug explained in his post. I tested against boxes I know I can discover and it worked, and I tested against the boxes I'm currently having issues with and it didn't work. 

There was a suggestion that perhaps there is a DNS issue with the boxes in question, but I used the FQDN to verify port 135, and the FQDN in the psexec method. So, I wouldn't think I'm experiencing a DNS issue. 

At this point I feel pretty confident that the issue isn't on my end. However, my core services team is confident the issue isn't on their end. Curious if anyone has any suggestions on what else I can do to prove the issue isn't on my end. 

Thanks!

[Scott Braden]

Just wanted to update this a bit and see if anyone has experience with this. 

I engaged my Security team today and they informed me that they have the devices that I am having issues with locked down to not accept connections initiated via IP. They are only allowing connections initiated via FQDN. They've informed me that this is in keeping with best practices and that Microsoft themselves are working to disable this more basic form of Authentication to their Operating Systems. 

I was able to "Test Credential" using the FQDN of every device in question and they all returned a success. When I try via IP they still fail. So I believe the information I am being given is correct. 

Curious if this means I need to install the Agent Client Collector on the impacted devices. 

[pratik0306]

hi Scott,

you mentioned in your previous update that- it works when you test via FQDN. Did u also verify if the DNS mapping is correct for the devices you are facing issue with? Also, if you ping the device from MID server then what is the result?

[Scott Braden]

We did in fact have a DNS mapping issue initially. We didn't have PTR's set up which was creating a situation where the ServiceNow DNSUTIL function wasn't able to run the Reverse Lookup. This has been corrected and now we can test the credential via IP and it succeeds. However, we still get failures when trying to run Discovery. It seems that when ServiceNow is running additional Powershell Scripts it isn't using the HOST NAME and is instead trying to use the IP Address. Which objectively seems odd since for authentication ServiceNow knows to do a reverselookup on the IP to get host name.