LDAP authentication with userPrincipalName fill with email address

[fritoss007]

how can I make LDAP authentication working with userPrincipalName fill with email address ? I guess there must be some patern check in php that prevent the use of @ ?

thanks for your help !

[george1421]

@fritoss007 said in LDAP authentication with userPrincipalName fill with email address:

Should I report it somewhere else

In this tread is good enough. Both Tom and Sebastian are in this thread so its the right place at the right time.

[fritoss007]

@george1421 so funny I knew it :)…I’m just wondering if it worth opening a new thread! I feel like it’s going to be much harder than the web interface!

But yes it’s working great for the GUI. Should I repport it somewhere else ?

[george1421]

@fritoss007 said in LDAP authentication with userPrincipalName fill with email address:

Now…what about the PXE menu ? I guess it’s a different story ?

Different story == Different thread.

FWIW the developers are thinking about making this a feature (allowing login via UPN/email address) in 1.6.x versions of FOG. So reporting back that its working is a pretty good way to make it happen.

[fritoss007]

@george1421 Thanks I would think the lenght of 40 is plenty as only tech will use this interface with their very special “admin” accounts.

@Tom-Elliott Thanks as your last string works like a charm!

So I’ve created 2 LDAP connections, one with userPrincipalName and the other with sAMAccountName so if users use any of them it will work !

Now…what about the PXE menu ? I guess it’s a different story ?

[george1421]

@fritoss007 Since the developers haven’t really looked into use email address or upn names for LDAP authentication can you do some research for them. If you could export you AD into something like excel and then create a quick formula to get the length of the upn name (could do with powershell too) and then post what is the longest UPN name (email) address you have in your AD. This would give the developers an idea if 40 characters is good enough or something else is needed.

[Tom Elliott]

One last bit, to make it a tiny bit more accurate, and compicated

^(?:[a-zA-Z0-9][\w\d \.\-]{3,40}|[a-zA-Z0-9\.%+\-]+@[a-zA-Z0-9\.\-]+\.[a-zA-Z]{2,4})$

This will make sure the first character is either letter or number (no underscore)

[Tom Elliott]

@george1421 @fritoss007

I think this regex would work best:

(?=^.{3,40}$)^[\w][\w0-9]*[._-]?[\w0-9]*[._-]?[\w0-9]*[._-]?[\w0-9]*[@]?[\w0-9]*([.]?[\w0-9])+$

This isn’t perfect, but should be closer to what’s needed.

Essentially, it’s looking at the final [.]?[\w0-9] and grouping it allowing us to add as many as wanted.

Here’s a slightly better version, I think, as it will allow normal usernames or email addresses:

^(?:[\w\d][\w\d _\-]{3,40}|[\w\d.%+\-]+@[\w\d.\-]+\.[\w]{2,4})$

In the above, it will only limit 3-40 characters without email. With email, the sky’s the limit. However, as @george1421 stated, the user field is only 40 characters so it would fail if you had anything larger than the field could accept.

[george1421]

@fritoss007 I’ve looked into the database bits too and the uName field is 40 characters log (that would store the upn name). So it should be large enough to hold most UPN names.

[fritoss007]

I might have spotted someting in the string I’m using…this is our fqdn : csdufer.qc.ca and I’m using this string :

‘/(?=^.{3,40}$)^[\w][\w0-9][._-]?[\w0-9][.-]?[\w0-9]*[.-]?[\w0-9][@]?[\w0-9][.]?[\w0-9]+$/i’,

should I use this instead ?

‘/(?=^.{3,40}$)^[\w][\w0-9][._-]?[\w0-9][.-]?[\w0-9]*[.-]?[\w0-9][@]?[\w0-9][.]?[\w0-9]*[.]?[\w0-9]+$/i’,

[george1421]

@Tom-Elliott said in LDAP authentication with userPrincipalName fill with email address:

I’m more inclined to think there’s an issue before this point (at which logging likely isn’t tracking).

I agree if you don’t know what you are looking for you will never find it.

[Tom Elliott]

@george1421 Logging has not been removed, so you can easily see if an account is failing to login for some reason. (Not necessarily the why it isn’t logging in).

If it’s making it to the LDAP plugin to check authentication, the request will be logged if it fails for any reason.

As it’s not making it that far, I’m more inclined to think there’s an issue before this point (at which logging likely isn’t tracking).

[george1421]

@Sebastian-Roth

Unfortunately there is no simple logging you could turn on. You’d need to add you own debug statements in the code to figure out what’s going wrong.

When I worked with Tom on the ldap plugin, I did have some basic messages logged. I know the code has been worked on since then so that debugging code may have been removed.

When we were first testing the mods a few years ago I had it working with the email address. Our focus was on getting the samaccount working with ldap reliably. If I remember right we made the decision to remove any special characters from the uid field because we ran into issues with non-low order ascii characters so Tom created those regex expressions to filter out everything except low order ascii.

One of the things you probably will run into is the UPN address will probably be longer than the field in mysql to hold the user account. I don’t really remember without looking but NT had a 15 character account limit and I bet the database field is pretty close to that. Some UPN names can exceed that length causing a login issue. Beyond the database issue, if the regex expression is updated the UPN name (or email address) should work without issue. You will still need to be mindful that the characters have to be low order ascii because the ldap program doesn’t support double byte characters at all.

[Sebastian Roth]

@fritoss007 Unfortunately there is no simple logging you could turn on. You’d need to add you own debug statements in the code to figure out what’s going wrong.

We might get @george1421 to take a look at this as well. He’s been working on the LDAP plugin code more than I have.

[fritoss007]

I did the change but the system still refuse to authenticate my email based username from userPrincipalName AD attibute. Is there any logs where I can follow what’s going on or maybe I can test the authentication ?

[Sebastian Roth]

@fritoss007 Oh yes, seems like I missed that part, sorry. Comment the check here as well and see if it works: https://github.com/FOGProject/fogproject/blob/master/packages/web/lib/fog/user.class.php#L129

[Tom Elliott]

@fritoss007 If you make the change on the LDAP side, you will likely need to ensure that change is made wherever it’s checked (including the user file as referenced in the post you found.)

[fritoss007]

I tried comment/delete the uername format test without success.

I have found this post and I don’t know if this could be relevante :
https://forums.fogproject.org/post/109449

[Sebastian Roth]

@fritoss007 Yes, seems like the current LDAP plugin implementation does not allow for @ character in the user name. See code here: https://github.com/FOGProject/fogproject/blob/master/packages/web/lib/plugins/ldap/class/ldap.class.php#L259

So you might want to change /var/www/html/fog/lib/plugins/class/ldap.class.php on your FOG server and remove or comment those lines from the code. Let us know if it works for you and we’ll consider adding that change to the official code base.