Quoting Guy Teverovsky, from the post of Tue, 21 Jun: > For the sake of common sense, by any means try to avoid using SFU. It > opens up some very nasty black holes in AD sucking up any security you > may have already implemented in AD.
while I agree, it is however quite a headache to introduce a company with no serious Linux SA team (The R&D people know more about the platform) to the idea of running an LDAP server next to the AD server. to explain: when you use winbind and add a machine into the domain, the first time you look up a user she will be mapped to a local UID in an "idmap" database. the problem is, there is no hash function to map a lanman object's SID, and the idmap database fills up on a "first asked, first served" manner. this is a sick mess, since this means that if you have several machines winbound, they don't all see the same UIDs mapped to the same usernames, which makes NFS impossible. solution one - have one machine enumarate all the UIDs and then copy its idmap database, and do that again each time you add users to the AD (yuck) solution 2 - have the userinfo come from the AD, the authentication from the kerberos (as before) and ask Samba to map the ids according to LDAP (yuck again). that LDAP server can either run on a separate linux machine, or be the LDAP that is already part of the SFU, and so keeps those details inside the AD itself, with a "Unix attributes" tag in the AD management dialog. > Much cleaner way is to use only SFU schema extensions without having AD > playing NIS-wannabe. not NIS, just LDAP. the scheme extensions alone don't let you access them. the SFU adds the above mentioned tag to the dialog box. > Definitely think twice and test,test,test if you are going to implement > it in environment that counts the user accounts by thousands (or has > very low end DCs). well, it's not the case, but the slowness was horrible. I found a nice mid-way solution. the unix UIDs are served by NIS, but the passwords are authenticated over the kerberos from the AD. this was done by adding the kerberos to pam, but getting rid of winbind. > You should NOT run nscd on systems running winbind: > http://info.ccone.at/INFO/Samba/winbind.html#id2952021 > Running nscd collides with winbind which is already doing caching. True. indeed removed. Other issues that need resolving: * On winbound machines of the RHEL 3WS variety, I could "su - user" from root without any problem. not so on 3ES, where I got back "su: Invalid password". at some point it magicly fixed itself and I could not recreate it (good thing?). could it be a kerberos glitch? * On all these machines, perhaps because of the pam games, the .bashrc are not executed (not after su-, nor when you ssh into the machine). anyone care to point me in the right direction? the permissions on the bashrc are correct... -- Second hand smoker trying to cut back Ira Abramov http://ira.abramov.org/email/ ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
