Checking Root Domain step fails

[brentil]

Describe the bug

Module fails to fully validate against Windows Server 2019 AD. When trying to configure the module settings it always fails on the Checking Root Domain step but the Accessing Global Catalog and Accessing LDAP pass. We can see in the logs that the module successfully connects and pulls the user's information from AD but then fails on password validation. If we load the URL directly it kicks up the user/password prompt which does work for authentication.

/DesktopModules/AuthenticationServices/ActiveDirectory/WindowsSignin.aspx

The error we find in the logs for trying to save the settings or logging in is "A more secure authentication method is required for this server" which a variety of web searches suggest this might have to do with LDAP channel binding and LDAP signing.

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirements-for-windows

We've tried a variety of root domains settings using DC=LAB,DC=GROUP,DC=UNIVERSITY,DC=EDU and LDAP:// and LDAPS://LAB.GROUP.UNIVERSITY.EDU and they all fail on the Checking Root Domain step. We've also tried every Authentication Type too and none of them fix it.

Software Versions

• DNN: 09.04.04
• DNN: 09.07.00
• Module: 07.00.00

Screenshots

Error log

The below error is kicked out when trying to save the settings for the module to connect to our AD and also when trying to login.

AbsoluteURL:/Default.aspx
DefaultDataProvider:DotNetNuke.Data.SqlDataProvider, DotNetNuke
ExceptionGUID:a79338bc-e733-467c-ad09-dc287a6ce131
AssemblyVersion:
PortalId:-1
UserId:-1
TabId:-1
RawUrl:
Referrer:
UserAgent:
ExceptionHash:jWdkvuz8cHe6slf4z5+CKSx2sDE=
Message:A more secure authentication method is required for this server.
StackTrace:
   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_Name()
   at DotNetNuke.Authentication.ActiveDirectory.ADSI.Utilities.GetRootEntry(Path ADSIPath)
InnerMessage:
InnerStackTrace:
Source:System.DirectoryServices
FileName:
FileLineNumber:0
FileColumnNumber:0
Method:

[mrdibb40]

Did you ever find a resolution to this? We are having the same problem with DNN 9.08 and version 7 of the module.

[brentil]

We never did. We spent a bunch of time trying to figure it out but never could even get an idea of what was going wrong. We ended up going with AD-Pro Authentication. HOWEVER, the version of that on the DNN Store is very OLD and also doesn't work. We had to contact their support to get the newest version which does work.

[sawest]

There is not support currently in this module to bind to LDAPS. If your domain controller requires that then you will get an error message. After reviewing the code, this behavior is confirmed. If you add LDAPS to the front of your string, it will be stripped off and replaced with GC. For this module to connect to a domain controller, LDAPS will need to be optional, not required. I will make this a feature request. Hopefully I, or someone, can add this ability soon. I am currently working through the module on other issues and adding dependency injection.

[sawest]

duplicate #74

[RonStack]

I was receiving this as well. After looking through the logs through DNN I discovered mine was due to an authentication error. I changed the username to include the domain, e.g. domain\username instead of what I was using, username by itself.

[MaiklT]

This happens by default when using a Windows 2025 Domain Controller, as LDAP signing is the default setting in Windows 2025.

[sawest]

I don't have a good way to test this problem. I have pushed a new release with a code change that hopefully will help with this issue. I need someone to install and test and provide feedback if possible.

[MaiklT]

Thanks a lot for your efforts, @sawest! I will test that within the next days and give you feedback.

Are there any specific settings in the provider configuration necessary?

[sawest]

I am hoping this will fix the root domain error when updating the config. However, you may have to set the authentication type setting to signing instead of delegation. It would be good to test with delegation and see if logins work. If not, then switch to signing and see if that fixes it. This would tell us a lot and then we can add to the documentation.

[MaiklT]

@sawest Could you please provide a DLL created in debug mode + the associated pdb file? (Just for the case some exceptions are fired...)

[sawest]

I think I may have a way to test this in my environment after all. I will report back with what I find.

[sawest]

@MaiklT I added the obj folder to branch version 8.0.0. You can find the files you asked for in the debug folder of that folder.

[MaiklT]

@sawest Thanks! Will try it within the next days, and report the results...

[sawest]

From my testing today, I believe the the setting will need to be secure. The root domain methods are statically set to delegation, however. I am changing that to use the setting in site settings. I have had success with this test. I am binding to a new 2025 server that was throwing the same error listed here. I will push new code and pre-release soon that can be tested.

[sawest]

Release 8.00.04 is up that uses the authentication type in configured in settings to access the root domain. Try setting that to "secure" and see if the original issue still occurs. I have not been able to test login yet but have had good results with the error above. A log in test would be really good feedback too.