When LDAP doesn't supply email address allow user to set it

Yes, this makes total sense, otherwise half of the functionality of GitLab is dead in the water.

Milestone changed to 8.3

cc @jacobvosmaer @dzaporozhets for opinion on technical side.

I am not sure if this is a good idea. @dblessing why is LDAP not providing an email attribute?

Reading the zendesk ticket it seems that for this customer, some LDAP users have an email, some do not.

What I find difficult here is that I seem to remember that we removed the option to edit the email of GitLab LDAP users at the request of another customer, who wanted to centralize user administration in the LDAP server. If we just make the field editable again, we make them unhappy.

What I find difficult here is that I seem to remember that we removed the option to edit the email of GitLab LDAP users at the request of another customer, who wanted to centralize user administration in the LDAP server. If we just make the field editable again, we make them unhappy.

TBH both options seem reasonable. Not having a working email means that GitLab is not usable well.

There are two solutions for this customer without proper emails:

make it possible to edit email
just edit the LDAP entry. Is this not possible @dblessing? Seems a more scalable solution for them.

@JobV

Not having a working email means that GitLab is not usable well.

It's annoying, but note that a separate email can be set to be used on the profile, for notifications and for identifying commits.

@DouweM does that rereoute all emails? Including password etc?

@JobV Ah, you're right, it doesn't.

@DouweM I'm thinking now, do we want that, though?

@JobV What do you mean by that?

@DouweM making all emails go to the alternative, configured email.

@JobV Ah. Yeah, I don't think so. We want devise (account) email to still go the primary one. So I agree with you, we definitely need to allow LDAP users to set their email in this case.

@jacobvosmaer I completely understand that customers do not want users to change emails if LDAP has them. We should/could only have this option in the case that LDAP does not supply one.

I'm not sure how we can persistently determine whether it's LDAP supplied or not. For instance it's probably easy to see that we're using a 'temp' email but once a user changes it how do we know it's not provided by LDAP now?

The customer seems to indicate they do not control the company's LDAP and not all users have company email, perhaps. I agree LDAP should have a mail attribute but we can't require that.

@dblessing

The customer seems to indicate they do not control the company's LDAP and not all users have company email, perhaps. I agree LDAP should have a mail attribute but we can't require that.

So the question is, is it more of an edge case that they are not able to control the LDAP email or that another customer doesn't want people to set their own email? I have no idea.

The only solution is to make this optional, which is not great. @dzaporozhets thoughts?

I still don't understand one thing. If you don't have email in LDAP - why not just add it in LDAP?

The customer seems to indicate they do not control the company's LDAP

How is it even possible. They need to add new employees to LDAP somehow.

This is strange to me as well.

@JobV yes kind of edge case when you use LDAP but can not or don't want to add email there. I think current behaviour is pretty obvious. We say that email is taken from LDAP account. As admin who manages LDAP I would prefer users to use email from LDAP rather than allow them to change it. So I propose we leave it as is.

Fo cases when user has temporary email we can just add warning message like:

Your LDAP account does not have email address. Please ask administrator to add email address to your LDAP account

@dblessing can you talk with the customer about this? I think @dzaporozhets solution is the cleanest.

@dzaporozhets

The customer seems to indicate they do not control the company's LDAP

How is it even possible. They need to add new employees to LDAP somehow.

Someone in the company does, but not this particular development group. The customer says they asked the 'identity' group about adding emails to LDAP and their response was 'not all users will have email'...nothing more.

If we don't plan to accommodate this configuration I agree we at least need a message as @dzaporozhets suggests.

If we don't plan to accommodate this configuration I agree we at least need a message as @dzaporozhets suggests.

Yes, we'll leave this scheduled for 8.3 with that intent.

I'm the Customer. The problem is that this LDAP is an AUTH LDAP not the company LDAP. This LDAP is used by a lot of apps in the company to auth users. Users could be "internal"(we have them, with Email, in the AD and we have it replicated) or "External" (Added thru tools only in that LDAP)
In the external you have several posibilities, I'll write the both that are applying now in our problem:

External company outsourced for a project. One account to push data in our internal GIT to start our CI flow, no email is required for that, they use their own code repository and only push tags to allow us to deploy. Read next one to understand the email problem with that.
External person working in the house. He has his own company email, the email is not in our AD that is replicated to the AUTH LDAP. The account for them uses other templating and the email is not required because we do not provide mail service to them.

Also I need to add that in the manual appear "you can configure GitLab so that your users can sign in with their LDAP credentials" and sing in (AUTH) is not profiling and could not be together.

Regards.

@oteCortes we'll discuss your comments tonight and get back to you.

@oteCortes we've decided to implement a configuration option that would make it possible for your users to set the email.

Although we are wary of adding configuration, we didn't feel completely happy with not having a solution for your situation, so we're happy to add it.

We have to still decide on an implementation. The current milestone of 8.3 might be too soon if the implementation requires a lot of work, no promises on that.

@dzaporozhets @jacobvosmaer love to hear your thoughts on weight and implementation. 8.3 would be great to aim for, but I prefer something more realistic if this is not arbitrary, rather than missing the milestone (so 8.4).

@JobV I don't think we will need a configuration option, if we allow LDAP users who did not have their email set using LDAP to change their email. This would not change anything for the majority of LDAP servers that do already provides an email for every user.

We can keep track of whether the email originates from LDAP by setting an ldap_email flag when the GitLab user is initially created or is updated based on LDAP. When they change their GitLab email from the temp address to an actual one, the flag will persist. If the user then is assigned an email on the LDAP server, the GitLab account will automatically be updated and the flag set to false so that they will no longer be able to change it.

@marin you also had input on this.

@DouweM @JobV On the one hand it makes sense to add the configuration for the user who doesn't have set email in LDAP because they cannot use GitLab properly. On the other hand we allow the user to go around the sole purpose of LDAP and that is controlling all user details in one central place. I think that by adding the configuration we will make some other GitLab admins life more complicated.

Can we somehow just use the secondary email of the user for everything if ldap email is not set/real?

@marin I think that's harder than allowing the email to be changed. Also note that secondary email addresses are currently not verified, so I feel uneasy sending sensitive account emails there ("Key added to your account" for example).

I don't think we will need a configuration option, if we allow LDAP users who did not have their email set using LDAP to change their email

I think @DouweM suggestion makes sense. Its better than extra config option

Hi,

Disappointed to find this has changed. This was functionality that I was explicitly using in 7.13. Sometimes authentication mechanisms do not necessarily align with communication mechanisms.

Also note that secondary email addresses are currently not verified, so I feel uneasy sending sensitive account emails there ("Key added to your account" for example).

The purpose of a authentication system such as LDAP is about having a verified account and using shared authentication. Verification of emails in that scenario is quite different from a user who signs up with an email address where that is your only authentication mechanism. Also the functionality in 7.* was to set a secondary email as used for notifications. Was that not operating for everything?

In my case I have managed to get our active directory updated.

@rarevans we're not completely clear on what you are disappointed with. The current status is that we're making sure everyone can use LDAP, whether you have a working, set email or not.

I was disappointed to find that the email address retrieved through ldap was not customisable when not set but I can deal with it in my organisation.

For those that cannot influence LDAP administration, a workaround is to have users add a secondary email and set it as the preferred email. When a user sees that their email is wrong they will want to modify the primary email. Human behaviour. Perhaps when the email is read-only because it is derived through LDAP, a link to the secondary email page next to it would make adding a secondary convenient and intuitive compared to forcing users to seek out another settings page by navigation.

w.r.t LDAP. There will be companies that will not allow sub teams to have emails set in their LDAP provider. The email of those teams may be provided by different companies. That is the complexity and politics of businesses. This is a potential use case scenario for Gitlab.

Thanks

@rarevans

I was disappointed to find that the email address retrieved through ldap was not customisable when not set but I can deal with it in my organisation.

This is exactly what we're trying to solve here :) We'll make it editable if it's not set.

There will be companies that will not allow sub teams to have emails set in their LDAP provider. The email of those teams may be provided by different companies. That is the complexity and politics of businesses. This is a potential use case scenario for Gitlab.

When someone needs us to handle this, we'll look into it. We want to avoid over-engineering. Please let me know if this is the case for you @rarevans

Milestone changed to 8.4

Reassigned to @DouweM

mentioned in merge request !2502 (merged)

Status changed to closed by merge request !2502 (merged)

mentioned in commit a3a008f6

mentioned in commit b9fca478

mentioned in issue #13969 (moved)

mentioned in issue #14559 (closed)

Mentioned in commit pfjason/gitlab-ce@a3a008f6

Mentioned in commit pfjason/gitlab-ce@b9fca478

mentioned in issue gitlab#4419

When LDAP doesn't supply email address allow user to set it

Expected behavior

Observed behavior

Next steps

Designs

Child items ...

Activity

Admin message

Admin message

When LDAP doesn't supply email address allow user to set it

Expected behavior

Observed behavior

Next steps

Activity