Is it possible to precreate LDAP users?

I’m trying to perform a migration from a legacy vCloud Director environment to ManageIQ. I have about 200 VMs in the vCD that I want to extract their owner info, and assign to the correct owner in MIQ, however, none of the users have logged in yet, and I’d like for them to be able to see all of their VMs when they first login to ease transition/adoption.

I’ve tried using a REST API call to /api/users with {action:create…} but I get a “401 unauthorized”, though the same auth-token works for performing searches for vms and users via /api/users and /api/vms, and I’m authenticating as the super-administrator, so user creation should be allowed as part of the assigned role. I’ve tried with password value both set and unset with no change in behavior.

All of this is being done through Powershell, as that’s the most convenient interface for talking to vCD and making the rest calls to MIQ.

{
“resources”: [
{
“email”: “user@domain”,
“group”: {
“id”: 22
},
“userid”: “user@domain”,
“password”: “”,
“name”: “user”
}
],
“action”: “create”
}

Hello mmoritz,

The group must already exist when creating a user. ManageIQ does deliver with some pre-canned groups so one of those could be used or a new group could be created.

Here is a link to our API Documentation for creating groups:

I also have some example Ruby scripts for using the ManageIQ API that can be found here:

The Ruby example scripts for creating groups can be found here:

For user creation our API Documentation can be found here:

The Ruby example scripts for creating users can be found here:

JoeV

Thanks for the doc pointers and sample code references.

I just relooked at my code and found an incredibly stupid syntax error that seems to have been the source of the authentication issue, and I have how successfully created the user, but the user can’t login. I get a message that “Sorry, the username or password you entered is incorrect.”

the evm.log shows that the password authentication is working, but the login process is failing with the message “Validation failed: User: userid is not unique within region 0”, which makes me think MIQ is trying to create a new user, not use the existing user.

I don’t see anything in the API Doc that address any specifics required for creating an LDAP linked user.

The group I want to assign already existed (created manually and assigned a role).

I created a blog post to help diagnose ManageIQ auth issues.
See:
https://www.manageiq.org/blog/2018/01/troubleshooting-auth/#capturing-authentication-data-from-manageiq-db

Is the user already there as: user@domain ?

If you configured ManageIQ’s OIDC to return domain, which is usually the case, the userid will be the form user@domain.

If you used the API to create the user make sure it’s the same format that will be used when ManageIQ creates the user at first login.

I suggest: Login as a user that you did not create with the API and see what format is being used. It will most likely be “user”@“domain” but might just be “user”. Then when you create the users with the API make sure you use the same format that ManageIQ did.

I can login to autocreate a user with just “username” and the user is being created as username@domainname. I had noticed this when looking at existing accounts, so had already setup my API created users to use than userid format.

However, on second login for this autocreated user, I can only login if I set the username to “user@domain”.

I then tried with previously existing LDAP user and found I was no longer able to authenticate with just “username” with the LDAP password. But if I switch to “user@domain” my existing users and my API created users work correctly.

This seems to have changed when I did the pull to update from Ivanchuck-4 to Ivanchuk-7 last week.

So, i guess my original question isn’t really what I need to resolve any longer. I’d much prefer to be able to have people use just “username” to login.

So I think I have this sorted out, just in case anyone cares.

Using the “LDAP” authentication method, not the External (https) authentication method.

In order to allow people to login with just their “SAMAccountName” attribute (without the domain portion in the username field):
In the configuration for Authentication, “Get Groups from Home Forest” MUST be enabled. I had been trying to disable this since in our environment, we don’t have a need at the moment to map AD groups to different user roles, tenants or projects. This seems to not be possible while maintaining the convenience of short usernames. Disabling the “Get User Groups from LDAP” and “Get Groups from Home Forest” checkboxes forces users to login with their full user@domain username.

Since I had to use group mapping, I created a group with the same name as an AD group that covers what I hope will be the bulk of the self-service user population. This group is mapped to to the custom self-service Role.

From there, I was then able to create the users using the API with any group value, and on first login, the users account will get assigned to the internal group based on AD group membership.

Thanks for the pointers Joe, your hints got me to experiment, get confused, and eventually come to a solution that will work for our needs for now.