I filed this as a correctness bug, not as a security bug. There are some attacks that could be performed on such MFA schemes but that are not applicable in phabricator's security model.

I think the RFC should be followed.

So I just did some googling and came across the RFC for MFA, and this is
taken from the RFC:

I'd like to understand the reason behind this before moving forward.

I think this is more to conform with what everyone else does, I know Google and Apple don't let you re-use tokens even if they are still in the valid timeframe, not sure if there are specific reasons behind that besides the attack you came up with above.

Is there a specific security purpose behind this? That is, what attack is this measure aimed at defusing?

We might build this as a side effect, but there's been no actual interest in it.

Hi guys. Unfortunately, my organization is no longer using phabricator, so I'm not really able to maintain libphremoteuser at this time.

AFAIK, it is still the only way to this. I added some bits to it to automatically populate email and name when registering, for the case where authentication is done against an ActiveDirectory instance via kerberos and LDAP, which I published at https://github.com/make-all/libphremoteuser

In T814#142452, @craigem wrote:

Is using psigen's libphremoteuser still the only way to achieve this?

There's been no commits to his repo since 2013 and it is broken against current stable Phab.

Is using psigen's libphremoteuser still the only way to achieve this?

I guess I'm sort of OK with letting you make mailing lists administrators so they can pick up policy stuff. This is definitely pretty silly but maybe not only silly, and wouldn't hurt anything except for the other issues.

Since we haven't seen any other interest in this in the meantime (although maybe you have?), keeping it external is probably best for us -- it's conceptually something that we're comfortable with, but it's conceivable that you're approximately the only install using it. We'd be open to bringing it upstream in the future if there's more widespread interest/use.

I guess having it exist on github is good enough.

The original driver here was a very complex one (requiring instance-level, non-registration OAuth links to services) but that never went through.

• Mailing list users can currently be made into administrators. We should probably prevent this, because it seems silly. (Making a daemon an administrator is still silly, but doesn't seem completely unreasonable.)
  • Regardless, users can be marked as mailing lists and also as administrators in the database.
  • bin/auth recover will let you recover users who can not establish web login sessions as long as they are administrators, but should not.
  • When you recover such a user, a misleading error message is shown (session invalid). Instead, recovery should fail explicitly and/or the session error message should point at the root cause more directly.

And the easiest fix turned out to be just deleting the row from the database, as mentioned in T2549#88614.

We had a similar error while using LDAP as an auth mechanism.

Thanks for sharing but not luck again.
Will dig additionally.

@d.maznekov Here's my (working) config for an ActiveDirectory:
Hostname: IP of the DC
Port: 389
Base distinguished name: dc=company,dc=net
Search attributes: sAMAccountName
anonymous username: ldap
anonymous password: ***
username attribute: sAMAccountName
realname attribute: displayName
LDAP version: 3
No Referrals
No TLS
ActiveDirectoryDomain: DOM (domain name in short form)

Yes I'm feel like...stupid.
Tried all reasonable variants - admin, domain\admin, cn=admin dc=domain dc=com, always finish with exception.
If I should provide additional information, please advice.
Will give one more try and abandon the tool respectively, I don't want to make by hand 250+ users.

@d.maznekov - Configuring LDAP always feels like a chore.. Nothing stands out from what you posted. Out of curiosity are you using "optixco\admin" or "admin" for the bind?

Yeah probably don't provide additional data, but it's public secret LDAP attributes of MS AD 2008 structure as sn, cn or sAMAccountName, base DN as suppose to be ou=people, dc=domain, dc=com.
Anyway, things I've tried is:
1.ldapsearch to find suitable attribute for setup of phab:

@d.maznekov you don't provide any details for anyone to help you. I've successfully setup LDAP authentication against an OpenLDAP service. Unfortunately what settings you provide is very dependent on how your configuration and object structure in LDAP. If you want assistance you need to provide details. Here is probably not a good place for it, perhaps in a Ponder Question.

Sorry guys but 2 days can't setup LDAP auth against AD 2008.
My task is to allow existing user to login/authenticate with their domain user and pass to work in collaboration at Phab.
Tried everything what have means, tried all possible fields returned by ldapsearch and always end up with exception :(
Make few setups against OpenLDAP on Debian linux and no success again...
Can't think about import from LDAP before resolve this.

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.

Specifically, to completely log out of Phacility, you must currently:

This is 1-2 hours of work and can be slipped in somewhere if approved.

This is straightforward and probably <1 hour of work. It can be squeezed in if approved for prioritization.

Just as a note: I was thinking about this, and in fact, I cooked up a small (untested) patch for it to require Administrators to have MFA (see end of post) through a new setting.

I think projects/badges are a better approach for this.

Another solution to the mentioned use case would be to automatically put users into Projects (T3980 or external scripts until that is implemented) and then award Badges based on Projects (T9163).

Sorry, I made a mistake and didn't update my local copy properly before trying to reproduce this. This is an error on our side.

@chad, thanks!

bin/accountadmin <username>

Can I change password for user by manage mysql database?

I can't reproduce this. When I follow these steps, the workflow completes successfully.

Steps:

1. Visit auth form: http://goo.gl/s9JCln
2. Click on link "Forgot your password?": http://goo.gl/7e51lY
3. Visit reset form: http://goo.gl/f5dPq3
4. Type account email and click on button "Send Email": http://goo.gl/r7UChl
5. See success message: http://goo.gl/7Uavms
6. Visit mailbox and see mail: http://goo.gl/uHV0OG
7. Click on link in the letter and see error message: http://goo.gl/2EMJtp

I can't reproduce this (resetting my own password works fine), and this report doesn't include enough information to allow us to help you.

In T6707#98607, @epriestley wrote:

The way the logic actually works, I think the fix is really in PhabricatorAuthLoginController near line 117:
[...]

Thanks @chad for your effords!
Maybe it's related to the reverse proxy? Since I'm not very familiar with the techniques behind OAuth, I have no ideas what to test or look for - suggestions welcome!

FWIW, We use Google and Amazon here, and I just tested them without issue.

Thanks @epriestley for choosing a better issue description; sorry for my english ...

I can confirm on this install, only seems to be GitHub from my limited testing.

Okay, can you file a separate issue for that and I'll try to reproduce it? That's bad and not the expected queue behavior.

Generally we find that the commit / message parser tasks tend to get done first, and take up taskmasters that could be processing Harbormaster builds. This delays builds because we have less taskmasters available.

commits without UTF8 data in them effectively block the queue.