[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On Mon, Oct 20, 2008 at 2:45 PM, Tom Potts
<tompotts@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Monday 20 October 2008 12:15, Rob Beard wrote:
>> Steve James wrote:
>> > Those instructions look sane to me. I've never messed with 'bind_policy'
>> > before.
>> >
>> > Make sure you shut down nscd when fiddling with this stuff. It's a sod
>> > for tricking you into false assumptions. Keep it shut down until
>> > everything is stable.
>> >
>> > I recommend a simpler ldap.conf. You can make do with only three lines:-
>> >
>> > base dc=somedomain,dc=homelinux,dc=org
>> > uri ldap://officeserver.somedomain.homelinux.org/
>> > ldap_version 3
>> >
>> > I note that you have both 'host' and 'uri' fields set. Don't do that!
>>
>> Ahh I see.
>>
>> > I wouldn't bind as 'root'. Use a dedicated LDAP admin account, say
>> > 'admin', with a unique password. Beware that any client workstation
>> > administrator can see this password.
>>
>> Okay. Got to work that out now, in phpldapadmin I have three users
>> under the Users ou - rob, admin and joe.bloggs
>>
>> Although I presume it's not here that I should be specifying users?
>>
>> I did managed to get a bit further, turns out the password I was putting
>> in ldap.secret was wrong. I managed to extract the password out of the
>> phpldapadmin config files but again that's using the root account.
>>
>> > Unless you require a user to be able to make a change to her password
>> > from the client workstation, I wouldn't bind with admin privileges at
>> > all. You can then dispense with /etc/ldap.secret and you can be sure that
>> > the LDAP database can only be modified centrally. I let users change
>> > password using Usermin running on the LDAP server (or it could be on a
>> > separate, privileged machine)
>>
>> The server actually has an web interface for changing passwords which is
>> handy. However I did try taking out the authentication but it didn't
>> seem to accept it. Strange thing is that Thunderbird will pick up
>> entries from ldap when I use a basedn of dn=somedomain,dn=homelinux,dn=org
>>
>> > If getent(1) returns a valid entry, then your libnss has bound to LDAP
>> > OK. You should also find that file ownerships (ls -l) are correctly
>> > reported. But if you can't login, PAM isn't binding. What's in
>> > /var/log/auth.log?
>>
>> Well when I login as a local user getent was working okay. It wasn't
>> authenticating, not sure if this was because I was using the root
>> account or what. I then tried logging on which worked to a point, I
>> could login, the home directory was created but it would logout straight
>> away. The .xsession-errors file mentioned something about user ??? not
>> existing.
>>
>> Trying to login to the console itself would allow me to login (after I
>> did a symbolic link from /bin/bash to /usr/bin/rssh) but it would
>> complain about group 500 and 5000 and then come up with something like:
>>
>> I have no name!@testbox:/$
>>
>> > You can serve {crypt} or {md5} (and others) from your LDAP database and
>> > of course PAM must correspond. I recommend the phpldapadmin package for
>> > adjusting the database via a web page. It also has a password verifier
>> > feature where you can check if the password hash in the database matches
>> > a password you enter.
>>
>> Cool, I'll have a play with that. I'm just worried about making too
>> many changes.
>>
>> The server is based on CentOS and from what I understand the group
>> numbering is different to Ubuntu?
>>
>> I can't help but think it would have made life easier using Ubuntu on
>> the server and desktop but this server has got everything with a nice
>> web interface which makes it easier for the users to administer when I'm
>> not around.
>>
>> > I have the working configuration files in a backup. I can root them out
>> > if you're still stuck.
>>
>> Cool thanks, I'll have another play and let you know how it goes.
>>
>> > Good luck,
>> > Steve.
>>
>> Rob
> Best of luck with this - could I beg for a precis after you've done?
> I've felt for a long time that LDAP should really be configured as the defacto
> security setup for any system so you can expand smoothly without any real
> fault lines.
> If we can get an idiots guide that works first time mos of the time....
> Tom te tom te tom
>
>
> --
> The Mailing List for the Devon & Cornwall LUG
> http://mailman.dclug.org.uk/listinfo/list
> FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html
>
This project may be quite well-suited to what it is being done:
http://karoshi.linuxgfx.co.uk/
It is based around schools, but has its uses.
regards,
KevinT
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html