Login succeeded but, but user information for "<User>" could not be found when no search bases defined

[mycroes]

Affected library

• [X] Visus.LdapAuthentication (Just guessing, didn't verify)
• [X] Visus.DirectoryAuthentication

Environment

• Library version 0.12.0

Summary When no LdapOptions.SearchBase is defined, the error Login succeeded but, but user information for "<User>" could not be found when no search bases defined is logged. Ran into this issue due to documentation / code misalignment from #13, so my configuration wasn't properly propagated. This should probably error at startup, because I assume having no search bases is always invalid.

What are you doing? Logging in with valid username and password.

What is the problem? The login succeeds, user information can't be found because there are no search bases.

What behaviour did you expect? An error indicating no search bases are defined.

Additional context This might perhaps be solved/validated with options post configuration.

[crowbar27]

Options validation is on my list, I haven't made up my mind what should be checked at startup (whether there is a base or whether there is a base that actually exists).

[mycroes]

It's been a while since I've actively used an LDAP server, so I can't remember if it's possible (and makes sense) to search without a search base. However, Visus.DirectoryAuthentication will not search at all if no base is defined, so if the intended behavior is to search without a base then there should be some fallback. Then again, you currently can't specify scope either without specifying the search base and you can't have a null search base because it's a dictionary key.

Expanding this rationale should result in cases where the library will currently have to reject the login due to missing information, I guess all those situations should be validated upfront, regardless of the fact that it doesn't mean any of those settings is actually correct. Maybe it makes sense to have sane defaults for Visus.DirectoryAuthentication that will let it use the Active Directory schema, but I don't think that's a valid choice for Visus.LdapAuthentication.

Either way, I'm a happy user of the library, made it pretty easy for me to do LDAP/AD authentication for that specific case where the customer doesn't want to provide AD SSO.

[crowbar27]

With ADDS, I usually get the default naming context from rootDSE and apply this as fallback, but I need to check whether this is possible with AD Protocols/Novell.

[crowbar27]

OK, it seems you can search on null, but only to get the root DSE, at least in DirectoryServices.Protocols.

[crowbar27]

I am not yet decided on whether to generate a validation error or fixing it at runtime to use the default naming context. In the meantime, you could do the latter with the LdapConnectionExtensions.GetDefaultNamingContext extension method.

[crowbar27]

Version 0.16.0 adds an options validator.