"Failed Receiving Server DH Public Value" Error - Sep. 20, 2005

BorderManager 3.8 Client-Site Authentication Error with NMAS NDS Method

Update - Sep 20, 2005

The most common reason for getting this error has to do with a change to how NMAS authentication works after applying NW65SP3. A beta AUTHGW.NLM patch was available from Novell for some time, and I think it is now in the latest version of BM38SP4 (beta). The symptom comes up if you call out users, groups or containers in your authentication rules. You should not have the issue if you have an authentication rule to allow Any NMAS user (which is an easy way to test for the problem).

Original Note, 2004

This one comes up for a lot of people, and I'm sorry to say that part of it is incorrect information on page 732 of my Beginner's Guide to BorderManager 3.x, Beta 1 (November 13, 2003). -[Well, that's why it was released as beta!] I have added a note on my errata page for that version of the book.

The problem is usually fairly simple. When configuring an authentication rule for NMAS Authentication in the Client-to-Site Configuration in iManager, you have a drop-down list for 'Minimum allowed authentication grade', which defaults to 'Logged'.

In my book, I show that as set to 'Password'. Seemed natural enough, and after a problem here and there, I thought I had it working.

Well, you want that value at 'Logged'. If you set the value to 'Password', you will probably have the error noted in the title of this page.

It is interesting how I came to leave that setting in my book, thinking that it was working fine. When I first set it up, I left it at the default, and C2S worked. I later changed it to password, and got the DH error. But I did not realize WHY I was getting the error, and found a workaround - I changed the rule order by creating another rule (a dummy rule is fine), and then changing the rule order. A forum user reported today that this workaround does fix the problem, but the reason it does is probably due to a bug - changing the rule order can result in that setting getting changed back to 'Logged', something I had not noticed before. Sure enough, when I looked at my rule tonight, it had been changed back to 'Logged', which is probably why the error went away for me during testing.

Sigh...

Update - Feb. 11, 2004

I have not confirmed this yet, but you may get the same error if the BorderManager 3.8 VPN server is not holding a replica that includes the Security container for the NDS tree. (You can partition and replicate the Security container, so that you do not have to put a copy of the Root replica on the server).


Return to the Main Page