I have a setup where my auth is LDAP backed. I have org and team mappings that WHEN a user logs in they’re placed in the appropriate org and team.
I also have individual machine credentials created for users, which are backed by Hashicorp vault, but that doesn’t really matter much. I’m trying to set permissions so that each user is only allowed to use their own credential and not somebody else’s.
My problem occurs if the user has yet to log in for the first time, like when I rebuild our staging / dev environment. I can’t grant a permissions role to an account that doesn’t exist. So far I haven’t been able to pre-create the account in a way that will allow LDAP auth to still work for that account.
For now I have to go bother individual folks and ask them to log into the new system so that the automation that sets up their credential permissions can succeed, but this isn’t scalable.
What you're describing jives with how I remember LDAP / regular user accounts working, namely that if you want an LDAP account, the user _has_ to log in with LDAP first. If you create the account ahead of time and then try to log in with LDAP, I think awx will see that a regular account exists and not even attempt to look up the user using LDAP.
I think that the separation between LDAP / regular user accounts was made pretty firm to avoid a situation where:
1. Regular user account (say, an admin account) is created
2. A *different* user creates an LDAP account using the same username as in #1
3. awx grants the LDAP user access to the existing (admin) account on the basis that the names match
4. LDAP user has hi-jacked the regular user account and now has whatever perms that account had (eek!)
So, while it's a pain to have LDAP users log in before their accounts can be set up, it avoids this ^ situation.
That's the way awx works today (I believe). It seems like if we wanted to come up with some kind of feature where LDAP users are 'discovered' and stub accounts are created for them, we could do something like that, but I think that would be a new feature. Don't think we can pull that off with current awx.
I think the approach is, not had much experience to confirm this, to assign permissions to access/use credentials (or other AWX objects) to groups and put users in those groups.
that’s partly serviceable, if I create a group for every user, that exists only of that user, and include some sort of mapping system to put them into that group. Without the mapping system I’m still in the same problem space. I can’t add the user to the group until the user exists.
We add users to groups in LDAP and these groups are used as references to the permissions/groups in AWX. Is this something you can do? Sorry I don’t really understand the LDAP magic to add users to groups, just that it happens.
Yes I use that, but to get them all into individual groups I would have to, I think, discover every user possible, create a mapping entry for every user possible so that every user possible gets mapped into a group by themselves. That may take a bit of time to process
We do this as well. LDAP groups become AWX teams, and each team gets a project repo and exclusive rights to the templates within the project repo. It’s easy to map the groups in. I just don’t necessarily want to create single user groups/teams for every user.
This also prevents restores from tower-cli to work properly.
For example the template restore with tower-cli will fail if the user that created the template it’s not in the system yet, and so for all the other tasks.
