This task is kind of all over the place, but I expect it to be functionally resolved by changes attached to T13244 in service of (internal) PHI774.

Sorry, yeah, I meant T6703.

I believe that instead of T7667 you meant to write T6703.

There are two flavors of this:

This isn't a bug. Here's an example of why the proposed behavior is dangerous:

Ah yes I forgot about the fun of internationalization. Btw those fragments are correct 👍🏻 (I speak Spanish).

Strings with sentence fragments like that can be difficult to translate in the normal human language sense, see:

The translation.override settings seems to be the easiest path forward. I definitely don't want to be modifying the source if I can help it.

This is probably something we'll need in the very long run for T6703 (if we legitimately let you connect to two different LDAP servers, it would be silly to have two "Login with LDAP" dialogs) but, yeah, using translation.override or just editing PhabricatorLDAPAuthProvider might be the shortest path today.

Can you just override the translation? /config/edit/translation.override/

Essentially I would like to customize the "Login or register with LDAP" here to be "Login or register with OpenDirectory"

In T2549#25878, @epriestley wrote:

• I deleted the @mierle account.
• It's currently not possible to link a Phabricator account to more than one external account of a given type (where "type" is one of "Facebook", "Google", "GitHub", etc.). In hindsight this was an architectural mistake, but I didn't think about it at the time and left us with a mess to clean up. It will be resolved by {T1536}, which is a sort of umbrella task for remedying various missteps on the auth pathway. We've made some progress on that, but it will be at least a little while before it lands.

I'm just going to merge this into T5953. The LDAP importer is a contributed patch from yesteryear which we wouldn't bring upstream today, and unlikely to see improvements outside of a more formal upstream effort in T5953.

Phabricator is not an LDAP administration tool and we have no plans to turn it into one.

I think this was building up toward T10939, and the actual solutions we're looking at there probably don't involve this.

In T10621#165969, @epriestley wrote:

How do you imagine Phabricator learning about the existence of new external groups? Just polling a list of every group in LDAP every hour or whatever?

In T10621#165969, @epriestley wrote:

How do you imagine Phabricator learning about the existence of new external groups? Just polling a list of every group in LDAP every hour or whatever?

How do you imagine Phabricator learning about the existence of new external groups? Just polling a list of every group in LDAP every hour or whatever?

This is also a problem in my environment - jpegPhoto populates correctly for other applications but not Phabricator

This task doesn't contain enough information for us to reproduce the problem you're encountering. Please see Contributing Bug Reports for an outline of what we need in an actionable bug report.

Would love to see this as an option. Biggest issue for me is AD servers using non-wildcard certs, and our need to connect to a subdomain with round robin dns to any of our AD servers. Having creds sent in plain text is not very good. Its not great that we have Cert errors but we're limited in our ability to fix that.

I would guess this is not an uncommon setup: many LDAP instances have self-signed certificates. Without this knob many standard LDAP setups would not work.

We're not likely to add this into the upstream. Mostly, we're very allergic to adding configuration options (and plan to remove many this year). It could easily be maintained in a fork or local patch.

I assume that was handled by the password envelope

In T7692#104265, @epriestley wrote:

In some setups, your patch allows any attacker to log in to any LDAP account by just not typing a password.

I assume my patch does not change current behaviour for others

In my authentication module I have e.g. this code for my PhutilAuthAdapter:

public function getAccountRealName() {
  $username = explode("@", $this->getAccountID(), 2)[0];
  $provider = PhabricatorLDAPAuthProvider::getLDAPProvider();

It is expected that this block will handle the case you describe, note the comment about rebinding with anonymous credentials and the actual rebind lower down.

Yes, upgrading MySQL from 5.1 to 5.5 has resolved the first problem. Thank you.

In T7366#98182, @epriestley wrote:

It is possible that this is caused by a combination of:

• Old MySQL, causing collation issues (T7287);
• the email address having uppercase letters; and
• the inbound mail handler changing letter case.

You could test this theory by:

• Verifying that you have a version of MySQL older than 5.5, then upgrading, running bin/storage adjust, and trying again; or
• replacing the email address attached to your account with a lowercase version and trying again.

It is possible that this is caused by a combination of:

These features work for the rest of our users and this installation, so this is very likely a configuration issue. I'm going to resolve this as "Invalid" under that theory as we're here to fix issues with the software and not provide configuration support. That said, here's some light configuration support, and please do let us know if you can prove this is a software bug with Phabricator.

Unless you specifically instructed the users who did click the links to immediately go to Settings > External Accounts and link their LDAP accounts, they're not really in better shape: they'll get locked out of their accounts as soon as they log out, too. Their LDAP credentials are not tied to their accounts. We never tie credentials together based on email addresses or usernames, because these aren't trustworthy across authentication sources.

Unless you specifically instructed the users who did click the links to immediately go to Settings > External Accounts and link their LDAP accounts, they're not really in better shape: they'll get locked out of their accounts as soon as they log out, too. Their LDAP credentials are not tied to their accounts. We never tie credentials together based on email addresses or usernames, because these aren't trustworthy across authentication sources.

This seems to have gotten a little bit too deep, but I might be misunderstanding something.

In the long run, I think the ideal workflow here is to make import/create more of a function of providers -- so you enable LDAP and get "Import from LDAP" (users would recover by logging in with their LDAP credentials), enable Google and get "Import from Google" (users would recover by logging in with their Google credentials), enable Facebook/GitHub/Whatever and get "Import from list of accounts in a CSV file" or something (users would recover by logging in with their service credentials), and enable username/password and get "Create New Account" (users would recover via password reset -- I think they already get cued about this, maybe?). We could let you "Create New Account" anyway, maybe, but since you can do that via the CLI if you really intend to do advanced stuff it might be more straightforward to simply remove it from the web UI.

(That title might be a little clearer?)

On SAAS, I believe the current plan is zero LDAP support, so it's moot.

Possibly we should have some kind of warning on People > Create New User if password auth is not enabled, since it's a confusing/advanced feature in that case (users must follow the links promptly, must link an external account, can not recover credentials, and don't get UI prompting).

I don't have everything set up locally, but two general pieces of information:

I'm actually not familiar with the LDAP stuff as I don't have a working LDAP server. Adding in my cohorts though.

Support Impact This is just completely broken and possibly destroys or mangles data.

✘ Merged into T5579.