LDAP users with RBAC Roles

I have an issue with integration between Microsoft LDAP users and RBAC roles defined in a Solaris box.

to explain more , i managed to integrate Microsoft Active Directory user loggings to Solaris boxes. I've done it to centralize user repo. and instead of creating admin accounts on more than 100+ production servers, i can login with my AD credentials.

I have configured RBAC so i can stop using root account for administration and use Primary Admin role or convert root into a role and use it with my AD user.

the problem is i can use RBAC roles with local users stored in /etc/passwd. i want to over come this and use rbac roles with my AD user.

Can Anyone help please ?

Appreciate your reply ASAP :confused:

---------- Post updated 01-25-10 at 10:38 AM ---------- Previous update was 01-24-10 at 12:06 PM ----------

Can't Anyone help !!
i have to this within a couple of days

Hi, not an solution, rather workaround - I also have to do authorization/authentification on solaris environment with MS AD; rather than sticking with RBAC + AD, I preferred the sudo + AD solution, but only because I do have solaris 8/9/10 all the road...

If you`ll not succeed with RBAC - perhaps you should try sudo way?...

Regards,
Nik

Like JAVA and OpenSolaris , RBAC is one of three things that are not good for usage , RBAC works only with Solaris , it is better to use read write permissions on group of users on some directory

??

Permissions are unlikely to replace the Solaris "Primary Administrator" role features.

mduweik: It is perfectly possible to have roles managed by an external LDAP directory. Before trying to use Active Directory, you probably might try first following the supported path, i.e. using Sun Directory Server as a back-end and initializing it with the Solaris supplied script idsconfig. Alternatively, you might also use OpenDS which already has support for the Solaris RBAC related schemas, eg: SolarisUserAttr.

I do no want to be vulgar but Java, OpenSolaris and RBAC are products that I call garbage

Thanks for your feedback. Very informative, helpful for the open poster and grateful for the people like me having helped you on these subjects.

Thanks all for your valuable feebacks.

sorry for not replying earlier, i was busy trying to fix it and i managed to use rbac roles and profiles defined locally to be used by LDAP MS AD users.

it was more simple than i thought ..

all you have to do is define rbac properly then edit the /etc/user_attr manually and add a line per user.

Details below:

Configure RBAC:

  1. /usr/sbin/roleadd -u 2000 -g 10 -d /export/home/unixpa -m unixpa
  2. passwd unixpa
  3. /usr/bin/grep -i unixpa /etc/passwd
  4. /usr/sbin/rolemod -P "Primary Administrator" unixpa
  5. /usr/bin/profiles unixpa

file attached (snapshot) of /etc/user_attr line needs to be added for each MS AD user

then login with AD user normally , su to RBAC role and thats it , you have Primary Administrator Role.

soon ill finish documenting the complete procedure as proof of concept for the management , along with auto creation of home directories if it didnt exist using one of two options (compiled pam or auto_home with NFS).

sorry again for the late reply and thanks to you all.

whoever needs a copy of the document (within a week will be ready) inshallah, drop me and email of i can post it here too if needed.

Your solution is actually a workaround. It isn't taking advantage of what LDAP as a naming service is designed to, i.e. central management and unicity of the database.

that might be true if you think of centralizing different OS features into one !!
other would be having a separate LDAP for Solaris , which requires more effort in terms of support and maintenance.

thanks anyway

Your opening question was about avoiding maintaining admin users in 100+ servers by centralizing their accounts on a LDAP directory, AD in your case. Choosing to maintain the user attributes on each of these servers while it is possible to have this table stored on a single location is, in my opinion, not the best solution.