Hi,

> > it
> > would be much easier to grant users access based on AD group
> membership,
> >  but also it's significant to maintain the same uid/guid across all
> > servers.
> 
> As your googling has shown, there are many ways to do that.
> 
> In my experience, a winbind solution is the way to go. But unfortunately,

Oke, thanks to you all I've managed to configure winbind on 2 RH5 servers
which are now running for two months rock solid with autocreating users home
directories.

Added this to smb.conf to configure winbind with the RID idmap backend:

idmap domains = <domain>
idmap config <domain>:backend = rid
idmap config <domain>:default = yes
idmap config <domain>:range = 16777216 - 33554431
template shell = /bin/bash
winbind use default domain = yes
winbind offline logon = false
winbind normalize names = yes
winbind refresh tickets = true
# could be wise to disable enumeration
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = Yes
winbind cache time = 180


]# authconfig-gtk 
"User Information" : Use Winbind
Authentication  :       Use Shadow Passwords
                        Use Kerberos
                        Use Winbind Authentication
Options         :       creat home directories ...
                        Local autorization is sufficient

Tighten up permissions on auto-created home directories:
]# vim /etc/pam.d/system-auth-ac
session     optional      pam_mkhomedir.so skel=/etc/skel umask=0077

Set access restrictions via AD group(s):
]# vim /etc/security/pam_winbind.conf
require_membership_of=<AD group sid>


If kerberos is enabled, this takes precedence over winbind restrictions, so
I've modified pam:

]# vim /etc/pam.d/system-auth-ac
auth        required      pam_winbind.so use_first_pass
#auth        sufficient    pam_winbind.so use_first_pass
auth        sufficient    pam_krb5.so use_first_pass


Thanks again!
Andre


> both RHEL5 and RHEL6 set up some rather dumb smb.conf configurations if
> you use system-config-authentication (RHEL5) / authconfig(-gtk) (RHEL6)
> to set up the configuration. Especially, these tools don't configure your
> system to use a deterministic UID/GID assignment backend. I have added
> myself to the CC lists for https://bugzilla.redhat.com/show_bug.cgi?
> id=615230 and https://bugzilla.redhat.com/show_bug.cgi?id=606743 but
> recent activity on the bugs seems to indicate that it will take a long
> while before we end-users may hope to see an improvement.
> 
> After having run system-config-authentication/authconfig, I recommend an
> adjustment of smb.conf to look somewhat like this (the smb.conf will do
> if you just run winbind; it will normally need to be expanded if you also
> run Samba's SMB daemon):
> 
> ===================== smb.conf =====================
> workgroup = YOUR.DOMAIN
> security = ads
> realm = YOUR.DOMAIN
> idmap config YOUR.DOMAIN:backend = rid
> idmap config YOUR.DOMAIN:range = 16777216-33554431
> template shell = /bin/bash
> winbind use default domain = yes
> winbind offline logon = false
> winbind normalize names = yes
> winbind refresh tickets = true
> winbind enum users = yes
> winbind enum groups = yes
> winbind cache time = 180
> ====================================================
> 
> The important point of the above configuration is the choice of the "RID"
> idmap backend. The default backend in an RHEL installation will generate
> uid/gid numbers which will vary across servers.
> 
> Another adjustment that I feel needs to be made for Red Hat's AD-
> integration is which permissions are set for auto-created home
> directories. Both RHEL5 and RHEL6 seem to make auto-generated home
> directories World readable/executable.
> 
> So for RHEL5, in files in /etc/pam.d containing "pam_mkhomedir.so", I've
> adjusted, so that I end up with a pam_mkhomedir.so-line like this:
> session required pam_mkhomedir.so skel=/etc/skel umask=0077
> 
> For RHEL6, in /etc/oddjobd.conf.d/oddjobd-mkhomedir.conf I have changed
> instances of 0002 to 0077.
> 
> The first time a user logs in to the server using this setup, a directory
> called /home/YOUR.DOMAIN/username will be created. The permissions of
> /home/YOUR.DOMAIN "mother-directory" was very strange when I last saw
> it,
> on a RHEL6 installation; you may need to adjust the permissions of /home/
> YOUR.DOMAIN to drwxr-xr-x after the first user with an auto-generated
> home
> directory has logged in (but from then on, the permissions of
> /home/YOUR.DOMAIN stay unchanged).
> 
> 
> Winbind is not the most stable thing I've come across. E.g., I've been
> bitten by https://bugzilla.redhat.com/show_bug.cgi?id=565915
> Therefore, I usually setup at least one local account (e.g. an account
> like troels_local) with ordinary SSH-key based access before setting up
> winbind.
> 
> 
> If you have trouble joining the domain, look in /var/log/audit/audit.log
> for signs of SELinux getting in your way. If so, you may find
> "setsebool -P winbind_disable_trans 1" useful.
> 
> 
> So winbind is not without pain, but I couldn't get the other build-in
> method (using a combination of LDAP and Kerberos, but not winbind) to
> work well. And a third party tool that we used (Centrify) is too much of
> a hazzle, being a ... well ... exactly a 3rd party tool (no automatic
> updates, less well-known by search engines, no Red Hat support, ...)
> 
> --
> Regards,
> Troels Arvin <[email protected]>
> http://troels.arvin.dk/
> 
> _______________________________________________
> rhelv5-list mailing list
> [email protected]
> https://www.redhat.com/mailman/listinfo/rhelv5-list

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
rhelv5-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/rhelv5-list

Reply via email to