[Freeipa-users] Slight confusion about groups, netgroups, sudo rules etc.

[Sigbjorn Lie]

On 03/13/2012 11:27 AM, Eivind Olsen wrote:
> Hello.
>
> I'm currently looking at implementing IPA in a mixed environment,
> consisting of RHEL6, RHEL5 and Solaris 10 systems. The IPA server(s) is
> the most recent one bundled with RHEL 6.2.
>
> I have some general rules I'll need to follow as best as I can, but I'm
> not really sure how to do this in IPA without it seeming like a huge
> work-around. This seems easy enough had it been for a pure RHEL6
> environment, but with Solaris there's no SSSD, I apparantly might need to
> downgrade the encryption types for "older" Solaris 10, etc. All of this is
> making my head dizzy, and I'd appreciate any help and pointers to clear my
> mind :)
>
> Examples of the basic rules are (there's more of them, it's not only for
> the DNS servers for example, but the other cases can be solved in the same
> way):
> - all sysadmins should be allowed to log into every system in the realm
> - all sysadmins should be allowed to run certain commands (or to make it
> easy, any command) through the use of "sudo", on all systems
> - some users will be part of certain groups, giving them permission to log
> into certain servers and run a set of commands through "sudo", for
> example: members of the dns-managers group should be allowed to ssh into
> the DNS servers (which consist of both RHEL6 and Solaris 10), and run
> certain commands through "sudo"
> - certain other users will be allowed to log into some systems, but
> without any additional access through "sudo" (the fact that they're
> allowed to log into system X doesn't mean they should be allowed to become
> root, etc).
>
> I've read a suggestion about making a host group for the Red Hat systems,
> a netgroup for the Solaris systems, and creating a user group which is
> added as a member of both the host group and netgroup. But, will I still
> need to worry about the old issue of Solaris apparantly not coping well
> with users that have>16 additional groups to their name?
>
> I have also read about having to add / change compatibility plugins,
> having to downgrade the algorithm for the Solaris 10 encryption type for
> older Solaris 10 releases, etc. And there's probably a few more things I
> need to watch out for and that aren't directly mentioned in the IPA
> documentation.
>
> Oh, in case it matters - there's no common NFS home directories, so I'll
> also need to automatically create the home directories (I've got this bit
> sorted on RHEL6 with help from oddjob-mkhomedir). For Solaris, I've read
> suggestions about using executable autofs maps to create home directories
> in /export/home and have tham loopback-mounted to /home so they match the
> homeDirectory attribute.
>
>

Hi,

I have implemented Solaris 10 with IPA with success. AES256 did not come 
to Solaris 10 until around update 7 or 8. There is still a bug where the 
required crypto provider is not enabled.

Check with:
# cryptoadm list
You should have "pkcs11_softtoken_extra.so" listed for aes256 support. 
If not, use the cryptoadm command to install and enable the provider. We 
have deployed the kerberos keytabs retreived with ipa-getkeytab without 
any limitations on encryption types for all Solaris 10 clients as soon 
as this provider was enabled.

For access restrictions on Solaris 10, adding a user group to 
AllowGroups in /etc/ssh/sshd_config is probably your best bet for 
locking down Solaris machines. We've used the netgroup way of 
controlling access to services with NIS, but I could not get the same 
working properly for LDAP.

There is also a nscd bug we recently discovered which keeps nscd 
stalling at random intervals, preventing user logins. Search at 
support.oracle.com, I don't have the patch number available just now.

More than 16 groups: NFS and AUTH_SYS with the Solaris NFS server still 
have an issue with more than 16 groups, as per the IETF standard. 
Solaris can still see all the groups with "# groups username". Using 
NFS4+Krb5 solves that issue. I have not met the 16 group issue anywhere 
else.

If you want to lock down your Directory Server to not serve anonymous 
users, you need a fairly recent patched Solaris ldapclient that supports 
"-D bindDN" and "-w bindPassword" options. "-a proxyDN" and "-a 
proxyPassword" is not enough as the Solaris ldapclient expects nisDomain 
in the directory root to be available anonymously.

I opened request https://bugzilla.redhat.com/show_bug.cgi?id=815515 for 
an updated DUAConfigProfile supporting more nss databases.

I also opened https://bugzilla.redhat.com/show_bug.cgi?id=815533 for 
updating the Solaris 10 IPA Client documentation.

Hope this helps.


Regards,
Siggi