Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checking Root Domain step fails #73

Open
brentil opened this issue Aug 27, 2020 · 5 comments
Open

Checking Root Domain step fails #73

brentil opened this issue Aug 27, 2020 · 5 comments

Comments

@brentil
Copy link

brentil commented Aug 27, 2020

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

image

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
Copy link

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
Copy link
Author

brentil commented Dec 30, 2020

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
Copy link
Collaborator

sawest commented Jan 26, 2021

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 sawest self-assigned this Jan 26, 2021
@sawest
Copy link
Collaborator

sawest commented Jan 26, 2021

duplicate #74

@RonStack
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants