A question about authentication between AD RMS server and AD server

%3CLINGO-SUB%20id%3D%22lingo-sub-970470%22%20slang%3D%22en-US%22%3EA%20question%20about%20authentication%20between%20AD%20RMS%20server%20and%20AD%20server%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-970470%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20having%20trouble%20on%20authenticating%20AD%20RMS%20server%20and%20AD%20server.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFirst%2C%20I%20want%20to%20explain%20the%20problem%20that%20I%20am%20having.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMy%20AD%20RMS%20server%20is%20trying%20to%20authenticate%20with%20AD%20server.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFirst%2C%20AD%20RMS%20sent%20LDAP%20message%3CBR%20%2F%3E%3CSTRONG%3E%22bindRequest(***)%20%22%3CROOT%3E%22%2C%20NTLMSSP_NEGOTIATEsasl%22%3C%2FROOT%3E%3C%2FSTRONG%3E%3CBR%20%2F%3Eto%20AD%20server.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%2C%20AD%20server%20returned%2C%3CBR%20%2F%3E%3CSTRONG%3E%22bindResponse(***)%20%22%3CROOT%3E%22%2C%20invalidCredentials%20........((snip))%20%22%3C%2FROOT%3E%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20googled%20this%20error%20message%20and%20find%20out%20that%20ID%20and%20password%20used%20for%20authentication%20were%20not%20correct.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWe%20have%20other%20AD%20server%20and%20AD%20RMS%20server%20tries%20authentication%20and%20successes.%3C%2FP%3E%3CP%3EAccording%20to%20packet%20capture%20result%2C%20AD%20RMS%20is%20sending%20same%20contents%20for%20success%20pattern%20and%20failed%20pattern.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHow%20can%20I%20solve%20this...%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIf%20the%20authentication%20acts%20properly%2C%20AD%20server%20will%20response%2C%3CBR%20%2F%3E%3CSTRONG%3E%22bindResponse(***)%20saslBindInProgress%20%2C%20NTLMSSP_CHALLENGE%22%3C%2FSTRONG%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESo%2C%20I%20also%20want%20to%20know%20in%20what%20condition%20will%20AD%20server%20send%3CBR%20%2F%3E%3CSTRONG%3E%22bindResponse(***)%20saslBindInProgress%20%2C%20NTLMSSP_CHALLENGE%22%3C%2FSTRONG%3E%3CBR%20%2F%3Eafter%20receiving%3CBR%20%2F%3E%3CSTRONG%3E%22bindRequest(***)%20%22%3CROOT%3E%22%2C%20NTLMSSP_NEGOTIATEsasl%22%3C%2FROOT%3E%3C%2FSTRONG%3E%3CBR%20%2F%3Efrom%20LDAP%20client%2C%20in%20this%20case%2C%20AD%20RMS%20server.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%20in%20advance%2C%3C%2FP%3E%3CP%3EAyako%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-970470%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EActive%20Directory%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1023511%22%20slang%3D%22en-US%22%3ERe%3A%20A%20question%20about%20authentication%20between%20AD%20RMS%20server%20and%20AD%20server%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1023511%22%20slang%3D%22en-US%22%3E%3CP%3EHi%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20problem%20was%20solved%2C%20so%20I%20will%20close%20this%20thread.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20reason%20was%20the%20AD%20that%20RMS%20server%20was%20trying%20to%20connect%20had%20wrong%20settings%20in%20local%20group%20policy.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSTRONG%3ENetwork%20Security%3A%20Restrict%20NTLM%3A%20NTLM%20authentication%20in%20this%20domain%3C%2FSTRONG%3E%3CSPAN%3E%26nbsp%3Bsecurity%20policy%20setting%20should%20be%20%22allow%20all%22%2C%20but%20our%20AD%20server%20was%20set%20as%20%22deny%20all%22.%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EAlso%2C%20registry%20setting%20was%20like%20this%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%20Key%3A%20%5BHKEY_LOCAL_MACHINE%5D%20-%20%5BSYSTEM%5D%20-%20%5BCurrentControlSet%5D%20-%20%5BControl%5D%20-%20%5BLsa%5D%20-%20%5BMSV1_0%5D%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%20Key%20name%3A%20RestrictReceivingNTLMTraffic%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%3CSPAN%3E%26nbsp%3B%20Value%3A%202%26nbsp%3B%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%2C%20this%20key%20name%20(RestrictReceivingNTLMTraffic)%20should%20be%20deleted.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAfter%20changing%20these%20settings%2C%20we%20finally%20experienced%20no%20difficulties.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESee%20you%2C%3C%2FP%3E%3CP%3EAyako%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
New Contributor

I am having trouble on authenticating AD RMS server and AD server.

 

First, I want to explain the problem that I am having.

 

My AD RMS server is trying to authenticate with AD server.

 

First, AD RMS sent LDAP message
"bindRequest(***) "<ROOT>", NTLMSSP_NEGOTIATEsasl"
to AD server.

 

However, AD server returned,
"bindResponse(***) "<ROOT>", invalidCredentials ........((snip)) "

 

I googled this error message and find out that ID and password used for authentication were not correct.

 

We have other AD server and AD RMS server tries authentication and successes.

According to packet capture result, AD RMS is sending same contents for success pattern and failed pattern.

 

How can I solve this...?

 

If the authentication acts properly, AD server will response,
"bindResponse(***) saslBindInProgress , NTLMSSP_CHALLENGE"

 

So, I also want to know in what condition will AD server send
"bindResponse(***) saslBindInProgress , NTLMSSP_CHALLENGE"
after receiving
"bindRequest(***) "<ROOT>", NTLMSSP_NEGOTIATEsasl"
from LDAP client, in this case, AD RMS server.

 

Thanks in advance,

Ayako

1 Reply
Highlighted

Hi

 

This problem was solved, so I will close this thread.

 

The reason was the AD that RMS server was trying to connect had wrong settings in local group policy.

 

Network Security: Restrict NTLM: NTLM authentication in this domain security policy setting should be "allow all", but our AD server was set as "deny all".

 

Also, registry setting was like this;

  Key: [HKEY_LOCAL_MACHINE] - [SYSTEM] - [CurrentControlSet] - [Control] - [Lsa] - [MSV1_0]

  Key name: RestrictReceivingNTLMTraffic

  Value: 2  

 

However, this key name (RestrictReceivingNTLMTraffic) should be deleted.

 

After changing these settings, we finally experienced no difficulties.

 

See you,

Ayako