Issues authenticating to API with a Windows group account

I've heard in the past of people who said they had to just delete AD groups from orion and re-add them to get them working again, but never run into it myself.

Here are some questions that may help with diagnosing the problem:

• Does the client machine where you are running SWQL Studio and PowerShell belong to the same domain as the Orion server that you are connecting to?
• If not, is there a trust relationship between the domains?
• Are you able to log into the Orion website using the same Windows identity you are using for SWQL Studio and PowerShell?
• Is multifactor authentication is enabled for the Windows account being used?  We have seen two or three reports of problems related to that, though we haven't yet been able to reproduce that in house.

You can also look for clues in the SWIS v3 log file right after attempting to connect:

C:\ProgramData\SolarWinds\InformationService\v3.0\Orion.InformationService.log

Try running the following PowerShell script, substituting the correct domain, user name, and password.  This approach doesn't involve Orion at all, but it can help you determine whether Windows is able to validate the credentials:

Add-Type -AssemblyName System.DirectoryServices.AccountManagement

$pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext @("Domain", "MYDOMAIN")

$pc

$pc.ValidateCredentials("MYUSERNAME", "MYPASSWORD")

Deleting and re-adding the groups did not help.

Dan,

Thanks for all of the information.

Answers to your questions:

• The clients and Orion server are on the same domain
• SSO works perfectly to the Orion UI with the same IDs we are trying in SWQL studio and PowerShell.
• Multifactor authentication is not turned on.

The provided PowerShell script returns "True" with the domain controller name, so it is connecting to the domain successfully.

Looking at the suggested log I see the following error when trying to connect via SWQL studio and PowerShell.  Can you help with this error?

2019-09-30 13:51:55,178 [111] ERROR SolarWinds.Data.Providers.Orion.OrionAccountValidator - (null) (null)  Failed to validate username and password for user 'XXXXX'.

System.DirectoryServices.Protocols.DirectoryOperationException: The server cannot handle directory requests.

   at System.DirectoryServices.Protocols.ErrorChecking.CheckAndSetLdapError(Int32 error)

   at System.DirectoryServices.Protocols.LdapSessionOptions.FastConcurrentBind()

   at System.DirectoryServices.AccountManagement.CredentialValidator.BindLdap(NetworkCredential creds, ContextOptions contextOptions)

   at System.DirectoryServices.AccountManagement.CredentialValidator.Validate(String userName, String password)

   at System.DirectoryServices.AccountManagement.PrincipalContext.ValidateCredentials(String userName, String password)

   at SolarWinds.Data.Providers.Orion.OrionAccountValidator.CheckWindowsAccountPassword(String username, String password)

   at SolarWinds.Data.Providers.Orion.OrionAccountValidator.CheckPassword(String username, String password, OrionMembershipUser user)

   at SolarWinds.Data.Providers.Orion.OrionAccountValidator.Validate(String username, String password)

Interesting...  What happens if you revise the PowerShell script to use the "Machine" option instead of "Domain" when creating the PrincipalContext​?

$pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext @("Machine")

> The provided PowerShell script returns "True" with the domain controller name, so it is connecting to the domain successfully.

What happens when you use the domain name instead of the domain controller name?

I verified from a couple machines and using the machine context it returns false.

I did use the domain name for this test.  Sorry, I meant to say my results returned the domain controller name.

Results:

ContextType     : Domain

Name            : <My_Domain>

Container       :

UserName        :

Options         : Negotiate, Signing, Sealing

ConnectedServer : <My_Domain_Controller>

True

Hello,

We have two SolarWinds instances, which are on the same version. However, I am getting 403 Forbidden when I try to access the URL

https://localhost:17778/SolarWinds/InformationService/v3/Json/Query

I checked the Information Service log and I noticed that I am getting the same errors reported in this posting.  By the way, I already attempted to fix the issue by uninstalling and then reinstalling the Information Service.  Still no luck.   Has anyone found a solution for this issue?

mr.e,

Working with support over the past few months our problem was related to a permissions issue.  Support is working on a fix to be added to the install.

We had to grant "Network Services" Read permission to the "C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys" directory to resolve the authentication issues we were seeing.

This was indicated by a reoccurring Schannel error that was found in the Windows Event log, category system.

Exact error example:

Error,10/21/2019 8:02:12 AM,Schannel,(0),<ORION SERVER NAME>,A fatal error occurred while creating a TLS client credential. The internal error state is 10011.