We are building a POC using OpenNebula 5.2.1 on Ubuntu 16.04 and so far is going really well.
But need some help on something that I haven’t being able to figure out…
Active Directory login and group mapping is working for 01 AD group. But when I try to allow login to a second AD group that fails either with a syntax/parse error or a message like "User xxxx is not in group CN=…"
Where “group CN=…” is the first or second group set for “:group:” on ldap_auth.conf.
My scenarios so far:
1 - Adding the second group on the same “:group:” line separated by space => Had syntax/parse error.
2 - Separating the groups by colon => There was no syntax/parse errors, but only accounts belonging to the first group could login.
3 - Adding a second “:group:” line => There was no syntax/parse errors, but only for accounts belonging to second group could login.
Is it actually possible to accomplish what I’m trying to?
Or… The way it actually works is having accounts authenticated by only one group, and once authentication takes place, I use AD group mappings based on the other groups the account belongs to? (To determine which view will be assigned to that account.)
I have attached a portion of our ldap_auth file with some if the information changed for anonymity.
If you are trying to accomplish the same thing as I was, this is how I did it. You can see in the group_field I have it mapped to a strange attribute.
This tells the system to search that group recursively, allowing all child nested groups to also work. my goal was:
have one parent group that is used as an ACL for login (to prevent people from logging in that aren’t in that group). this was to prevent service domain users and related from being able to login.
Then I wanted all the child groups inside of that group to get assigned to open nebula groups individually (development, support, customer service, etc).
By searching the group membership recursively, it allows using one group for (what I’m calling an ACL, maybe not the best term) with child groups inside that group to assign them to their various departments.
for the child groups you will have to add the group in open nebula and link it to the AD group using the Group_DN var in sunstone (or ssh, but I used sunstone)
the layout is basically cloud_users being the parent group, each group inside it is departmental level, with the user in each of those department groups. Hope this helps.
base hierarchy where to search for users and groups
:base: 'OU=users,DC=domain,dc=com'
# group the users need to belong to. If not set any user will do
:group: 'CN=Cloud_Users,OU=Security Groups,DC=domain,DC=com'
# field that holds the user name, if not set 'cn' will be used
#:user_field: 'cn'
# for Active Directory use this user_field instead
:user_field: 'sAMAccountName'
# field name for group membership, by default it is 'member'
:group_field: 'member:1.2.840.113556.1.4.1941:'
Thank you for helping and sorry for the delay to reply back. Too many things going on here…
What I am trying to accomplish is slightly different from what you have: instead of using a single group as entry point, using multiple groups as entry points.
Or… Authenticate against a single group, but being able to do mapping using the other groups (not nested) the account already belongs to. For example:
* Account John Doe belongs to “nebula_grp”, “unix_grp”, “storage_grp” and “app_grp”.
* ldap_auth.conf would have “nebula_grp” as the authentication group
* Group mapping would be defined based on “unix_grp” and/or “storage_grp” and/or “app_grp”
I’m not familiar with Ruby, but when looking at the “authenticate” script, it seams that it only accepts one single string as parameter for the AD group to search for authentication.
But your solution looks like another possibility for us. I’d have to check with our AD administrators if nested groups is something the can be implemented in our environment without breaking any of our standards.
If you don’t mind I ask, what is that strange attribute you are using? Is it the same for any AD version?
If in our environment we can have nested groups set up, I’d really like to give that a try…
Again, thanks a lot for helping. As you have noticed, OpenNebula is very new to me. I’m sure I still have a long road ahead…
I am also very new and have spent significant time in coming up with that solution.
I understand, you have a user with multiple group memberships and you want all of his group memberships to reflect on his single user. I do not have the ability to test that exactly, but you COULD do what I did with nested groupings. I don’t know how large your environment is or what you are working with, but if you took all the relevant groups and simply made one “placeholder” group to provision in with, you can then use the group_dn attribute to assign them to each group I think.
that strange attribute is not unique to our org, it’s an OID that is standard in (atleast our version) of active directory. I am not an expert on this and simply found that solution in a forum a ways back (actually, one of my developers in house did) and the test was successfull on mulitple platforms that use ldap tree search functionality.
in open nebula a user can only have a single primary group, but multiple secondary groups. I am not sure how you can define that in the ldap_auth file but I would bet there is a way.
the functionality between primary and secondary group is not the same though, so I would test this extensively.
I hope this helps in some way.
We have a large AD environment… And as this exercise is a POC, we still don’t have an exact idea of our users base.
But our AD guys are going to set up some accounts and groups (nested and non-nested) in their development domain, so I can play with your idea of nested and also with mapping secondary AD groups.
While that is not done, I’m starting what it seams to be the long road of deploying Windows VMs…
I’ll keep this post updated when I have the AD test accounts and groups to play with
Again, thanks a lot for taking the time to respond.
great! I hope my small amount of experience was helpful.
I am also in the process of automating windows deployments for our application server.
Let me know if you have any problems I may have run across them. It would seem not that many people are using the windows contextualization features here in the forums, probobaly because it’s basically just a glorified powershell script.
We had the nested groups created, I set the group mapping on our side and our tests went very well. Problem solved…!
Again, thank you for helping us with your solution…!
Windows VMs creation is going well. But we are not working yet with contextualization for mass deployment. That’s on another phase of our POC.
But thank you for offering your help on that. We may need some in the future…
