Local user: Cannot assign user name to account; name already in use.

[Olivier Croquette]

Hello,

I am setting up a new Gerrit instance using 2.15 RC2. I use LDAP (AD) as an authentication backend, but I would like to add a local admin user as backup. I have created it successfully using the command line:

ssh gerrit gerrit create-account --group "'Administrators'" --http-password passwd--email em...@domain.com  gerrit-admin

But when I want to log in with the corresponding credentials in the web interface, I get the error message:

Cannot assign user name "gerrit-admin" to account 1000005; name already in use.

Any idea?

Cheers
Olivier

[Edwin Kempin]

"ssh gerrit gerrit create-account ..." creates a service user that is not able to login in the WebUI (it doesn't have an external ID for web login).

I think what's happening is that on WebUI login it tries to create another user (because it doesn't see the user that you created before due to the missing external ID) and the username of this new user collides with the username of the user that you have created before.

Kinda WAI. With using LDAP only users that exist in LDAP are able to login in the WebUI.

 

Cheers
Olivier

--
--
To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Olivier Croquette]

On 2017-12-22 08:23, Edwin Kempin wrote:

"ssh gerrit gerrit create-account ..." creates a service user that is not able to login in the WebUI (it doesn't have an external ID for web login).

I think what's happening is that on WebUI login it tries to create another user (because it doesn't see the user that you created before due to the missing external ID) and the username of this new user collides with the username of the user that you have created before.

Kinda WAI. With using LDAP only users that exist in LDAP are able to login in the WebUI.

I see, thanks for the answer. Too bad that Gerrit doesn't support this use case.

Best regards
Olivier

[luca.mi...@gmail.com]

Sent from my iPhone

What would you expect to see?

It is good that a service user which is intended for batch and automation cannot be shared with a regular LDAP account user identity.

Can you explain why is this bad from your perspective?

Thanks

Luca

Best regards
Olivier

--
--
To unsubscribe, email repo-discuss...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

[luca.mi...@gmail.com]

Hi Oliver, see my feedback below

Sent from my iPhone

On 27 Dec 2017, at 11:52, Olivier Croquette <ocroq...@free.fr> wrote:

On 2017-12-27 08:18, luca.mi...@gmail.com wrote:

"ssh gerrit gerrit create-account ..." creates a service user that is not able to login in the WebUI (it doesn't have an external ID for web login).

I think what's happening is that on WebUI login it tries to create another user (because it doesn't see the user that you created before due to the missing external ID) and the username of this new user collides with the username of the user that you have created before.

Kinda WAI. With using LDAP only users that exist in LDAP are able to login in the WebUI.

I see, thanks for the answer. Too bad that Gerrit doesn't support this use case.

What would you expect to see?

It is good that a service user which is intended for batch and automation cannot be shared with a regular LDAP account user identity.

Hello Luca,

I don't want to share identities between local and LDAP accounts. I would like a pure local account that I can use to log in the web interface independently of LDAP.

That is forbidden on purpose: typically companies rely on a central LDAP Auth to define a unique way to create, manage and admin accounts.

If anyone leaves the company, you remove it on the central LDAP and all the systems are automatically locked up for him.

If you allow a non-LDAP user to be a full interactive user, then it would violate the company policies

It's not a very important use case, but I don't understand the limitation from a user perspective.

What is your use-case? Why an interactive user should not be registered in LDAP?

[Luca Milanesio]

On 27 Dec 2017, at 15:10, Olivier Croquette <ocroq...@free.fr> wrote:

On 2017-12-27 13:02, luca.mi...@gmail.com wrote:

That is forbidden on purpose: typically companies rely on a central LDAP Auth to define a unique way to create, manage and admin accounts.

If anyone leaves the company, you remove it on the central LDAP and all the systems are automatically locked up for him.

If you allow a non-LDAP user to be a full interactive user, then it would violate the company policies

Like mentioned earlier, the use case is a local admin account ("gerrit-admin") as a fallback. Many applications allow this, for instance Linux itself, Teamcity, JIRA... To decide whether this is good practice or not should be up to the given admins.

I do not see problems in having a local admin account with limited abilities. Possibly a change to be proposed on the Gerrit master code-base?

Already now, you could have an local admin account and do admin stuff using the SSH or REST API.

Bear in mind that a lot of the admin operations on Gerrit are not exposed in the WebUX and are available only via config file or SSH command.

An extension to access the admin Web UX would be a nice bonus and it would make sense IMHO.

Another use case I can think of is to use Gerrit standalone without an external authentication authority. There is currently no good solution for simple setups, for instance for evaluation or tests. That would be a step in the right direction.

There are actually two options for a standalone Gerrit setup:

1) The "Development_become_any_account" authentication

2) The Gerrit Docker image with integrated account management and backed by pre-installed LDAP server

You can run both using Docker, just have a look at the GerritCodeReview DockerHub organisation at:

https://hub.docker.com/r/gerritcodereview/gerrit/

HTH

Luca.

[Olivier Croquette]

On 2017-12-27 08:18, luca.mi...@gmail.com wrote:

"ssh gerrit gerrit create-account ..." creates a service user that is not able to login in the WebUI (it doesn't have an external ID for web login).

I think what's happening is that on WebUI login it tries to create another user (because it doesn't see the user that you created before due to the missing external ID) and the username of this new user collides with the username of the user that you have created before.

Kinda WAI. With using LDAP only users that exist in LDAP are able to login in the WebUI.

I see, thanks for the answer. Too bad that Gerrit doesn't support this use case.

What would you expect to see?

It is good that a service user which is intended for batch and automation cannot be shared with a regular LDAP account user identity.

Hello Luca,

I don't want to share identities between local and LDAP accounts. I would like a pure local account that I can use to log in the web interface independently of LDAP.

[Olivier Croquette]

On 2017-12-27 13:02, luca.mi...@gmail.com wrote:

> That is forbidden on purpose: typically companies rely on a central
> LDAP Auth to define a unique way to create, manage and admin accounts.
>
> If anyone leaves the company, you remove it on the central LDAP and
> all the systems are automatically locked up for him.
>
> If you allow a non-LDAP user to be a full interactive user, then it
> would violate the company policies

Like mentioned earlier, the use case is a local admin account
("gerrit-admin") as a fallback. Many applications allow this, for
instance Linux itself, Teamcity, JIRA... To decide whether this is good
practice or not should be up to the given admins.

[Doug Robinson]

FWIW, we have customers for our ALM products who are in 2 buckets:

1. Those who ONLY WANT LDAP, for exactly the reasons that you state below (person leaves the company, they disable the account in LDAP and it's disabled everwhere).
2. Those who want both local and LDAP accounts (clearly, the names can't conflict).

So we ended up having to have a tunable that enables "A pure LDAP environment": either true or false.  If true the there can be no local accounts.