[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Tom Potts 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
>
>
Yeah, well once I know it is working and it's not just a one off fluke
(like I got with WINBIND authentication) I'll post up some details to
the list.
Rob
--
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