| |
| |
| |
|
Page: 1 2 3
Comments:
<0> sneak: if you'd use "uid=<username>,ou=<subou>,dc=domain,dc=com" you could bind generically with just putting in the username - other alternative is your suggestion.. search them up anonymously, or using a service-user, and them bind using the dn of the user
<1> i didn't know you could bind generically using just uid
<1> i was under the impression you had to bind with a DN
<1> that's what all the docs say anyway
<0> no.. your script can auto-generate the dn using the username, was what I means
<0> s/means/meant/
<1> right now everyone is in ou=People,dc=domain,dc=com but i am going to break them into ou=officelocation,ou=People,dc=domain,dc=com
<1> and not everyone is in the same office, so they are going to be in different OUs
<1> with varying DNs in ways other than their uid
<0> is there a specific need to do so, or can you make them members of ous and groups instead of moving their account-objects into sub-ous
<0> what happens when you get the second person named John Smith at location2 ?
<2> hi folks. has the p***word-hash directive been gone in the newer openldap environment? how to say slapd to store all p***word hashes as ssha ?
<3> ctp: did you read the man pages?
<3> ctp: because it is *clearly* documented in the slapd.conf man page
<4> man slapd.conf;/hash ;p
<2> JoBbZ: ok, thx ;-)
<2> does ssha provide the strongest hashing compared to sha, md5 and smd5?
<4> ssha is sha1 + salt
<4> that's what the first s is for
<4> see man page for the techie details
<2> ok
<5> Ha ITS#4837. Yeah sure. 2 secs and we'll do it! ffs.
<5> Can I reply, "Certainly, when would you like this done by?"
<5> hyc: Pllleeeeaa***seeee ;-)
<5> done it ;-)
<3> ghenry: Well, maybe it should be a config parameter, rather than modifying the source. :P
<6> well, it would probably take all of a minute to fix.
<5> Sorry, I don't mean to point out the obvious, but OpenLDAP is an Open
<5> Source project which means the source code is available for you to patch.
<5> is what I said
<5> nice a polite
<5> s/a/and
<6> and IMO, anything that makes it easier for Sun users to switch to OpenLDAP is a good thing.
<5> agreed
<6> unless it means breaking LDAPv3 conformance to match their lack of conformance... :P
<5> if that e-mail comes across negative, feel free to bounch it
<5> I didn't mean it to
<5> their request just sounds like a demand ;-)
<5> I think JoBbZ is right
<5> to allow the salt as a config?
<5> night all.
<5> hyc: Can't they just set this to 8? p***wd.c:#define SALT_SIZE 4
<6> yes, most likely
<5> heh, night.
<3> night ghenry :)
<7> hey Guys, can I do a wildcard delete? ldapdelete -x -W -D "cn=admin,dc=gm" "cn=1*,ou=domain,dc=gm"
<7> to delete all entrys starting with 1
<8> ghenry, you here
<8> just looking for an init script for openldap, i couldnt find it in the source - the docs says to start it like /usr/local/libexec slapd
<8> which seems to work fine..
<8> hyc, what do you think - should i forget the init script?
<9> moin
<5> sendro: there's one mentioned on the faq
<10> it's not directly on topic, but I have to ask here
<10> anyone ever have m***ive problems with libnss-ldap and nscd combining to just... crash all the time?
<10> on linux
<5> i tend to switch nscd off
<10> how do you just... not use nscd?
<10> when it crashes on me, all the answers stop working
<5> /etc/init.d/nscd stop
<10> well, yes, but how do you get libc to be able to query the ldap server without it?
<10> if I stop nscd, all lookups that fall to the ldap server just 'fail'
<10> as far as I can tell they never actually happen
<5> it's just a caching daemon, it's not needed to the lookups, I tihkn
<6> right. on every system I've seen, stopping nscd doesn't break anything else.
<11> AFAIK, it breaks applications that are statically linked against glibc.
<6> sounds like a buggy glibc.
<11> Don't know exactly. But that's what the glibc-developers mention quite often as an argument against static linking (or against disabling nscd).
<6> yes, in a statically linked binary libdl is not present. libdl is the hook to the dynamic loader. without it, dynamically loaded nss modules cannot be used.
<6> but that's a fault in glibc's implementation of dynamic loading.
<11> Probably. But it seems they're not going to fix it soon.
<6> given how many years they've done things this way, likely not.
<6> but there are other platforms like AIX that don't have that limitation
<6> so it goes
<12> hachi, misconfigured nss_ldap
<12> permissions wrong, or no binddn/bindpw (and nscd is working via rootbindpw and /etc/ldap.secret)
<2> hm, i installed openldap under debian etch. the installer asked me to put in the admin's p***word, but dont know where he put it in. no p***wd hash in slapd.conf. anyone has an idea where and how the p***wd is stored?
<12> ctp, probably went into the database
<12> you can always set rootpw in slapd.conf
<2> _ranger_: if it went into the db, does ldap expect a certain dn to bind it for the admin? i use rootdn="uid=admin,dc=foo,dc=bar" and not the usual rootdn="cn=Manager,dc=foo,dc=bar". does ldap "know" to bind the stored p***wd to that dn?
<2> ctp: i always get a "ldap_bind: Invalid credentials (49)" ldapadding first data. thats my problem ...
<6> "ldap" doesn't expect anything.
<6> By default, slapd will try to bind the given DN to a userp***word in its entry.
<6> it makes one special case if the provided DN matches the configured rootdn.
<6> that's all.
<12> ctp, either you have a rootdn in slapd.conf, or you need sufficient ACLs as another DN
<12> if you have a rootdn, either you can have the p***word in rootpw in slapd.conf, or the dn could be stored as a usual entry in the directory
<2> ah, ok. thx for infos
<2> _ranger_: so avoiding the admins p***wd hash in slapd.conf (rootpw={SSHA}xxxxxxxxx), i can store it in the db itself?
<12> yes, which is AFAIK what the debian postinstall scripts do
<6> I wonder if it'd be worthwhile to extend p***wdModify to be able to update rootpw's under cn=config.
<12> but you can ldapmodify it anyway ?
<6> yes
<6> but using p***wordModify lets the server hash it
<12> I guess
<12> could ppolicy be used over back-config ?
<6> probably too much h***le. hm, ppolicy...
<6> not really. there are no entries under cn=config with userp***word attribute.
<12> There are security policies here for almost everything (e.g. requiring lockout on database accounts etc.), but maybe not for LDAP
<6> the only ID that's relevant to cn=config is its rootdn, and rootdn's don't obey any ppolicy restrictions anyway.
<2> _ranger_: do you have a hint how to change the admin p***wd the debian postinst script stored in db?
<12> ctp, if you know it, ldapp***wd
<12> if you don't, generate a new one with slapp***wd, stop slapd, slapcat, edit, slapadd, start
<2> _ranger_: ah, ok. didnt know ldapp***wd handles the db stored p***wds
<2> _ranger_: thx
<12> ctp, uh, it handles p***words for *any* LDAP entry that has a p***word
<2> ok
<13> Hello ldap people :P
<13> I'm new to ldap and I'm playing around with openldap and pam-ldap to manage account information (using kerberos for authentication) and I'm having some problems getting this to work
<12> nss does account information
<13> Not that I wasn't expecting any problems :-) But my problem is that I can't seem to find any information on what going bad, so I was hoping that someone might be able to point me towards some debuging methods
<6> if you're using kerberos for authentication, then pam_krb5 would make more sense.
<12> the only thing you would need pam_ldap for would possibly be authorization
<12> mrEriksson, well, what is not working, and what have you done ?
<14> hello :)
<13> hyc: Yeah, the kerberos part is working just great.. So that is not a problem :)
<12> mrEriksson, there isn't really very much that is ldap-specific here
<12> mrEriksson, does 'getent p***wd' work for users in LDAP ?
<13> Oh, so pam-ldap does nothing else than authentication? And I need pam-nss to retrieve account information ?
<13> _ranger_: Well, true perhaps, but my problem was that I did not get any log output from either pam-ldap or openldap,, But since pam-ldap doesn't do account information, I guess that could explain things :-)
<12> no, you need nss_ldap to retrieve information for nss
<12> nss == name service switch
<12> mrEriksson, well, you should maybe consider setting up logging for OpenLDAP ?
<13> Hmm,, Crap :( As far as I've understood things, pam_nss isn't supported on my platform (netbsd) :(
<13> _ranger_: That's what I did, but still didn't get any information, but I guess that isn't really strange since I tried to use pam-ldap for account-details :P
<12> mrEriksson, ????
<12> you need *nss_ldap*
<13> _ranger_: Yes, I've understood that now, but I didn't before when I was having the problem :(
<12> mrEriksson, the first thing you must do with any user account information is test to see if it is available to the OS
<12> pam is irrelevant until glibc can tell you anything about the user
<13> I don't really use glibc :-)
<12> so, you need to 1)install nss_ldap, 2)configure it for the ldap service you have (in /etc/ldap.conf), and 3)enable it (so that glibc uses it) in /etc/nsswitch.conf
<12> mrEriksson, if you don't specify otherwise, most people here will ***ume that "pam_ldap" means Linux
<13> _ranger_: Yeah, but the problem that I now face is that nss_ldap doesn't support my platform :(
<6> right, freebsd doesn't use glibc
<13> _ranger_: Oh, strange, since pam is far from linux-specific
<6> er, netbsd...
<6> yes, pam has become cross-platform. nss, less so.
<6> still primarily solaris and linux
<12> mrEriksson, ah, but you've been saying "pam_nss"
<12> which I have never heard of
<12> anyway, leaving early today .... bye
<13> Ehh, what da heck,, There seems to be an nss_ldap package for netbsd,, But I found lots of information stating that nss_ldap wasn't supporting netbsd.. Ohwell, I guess that problem is solved now :-)
<13> ranger: Well, sometimes, I have a hard time getting all these new expressions right :-)
<6> ranger left already...
<13> Doh :-)
<13> So, if I understand things correctly, when doing authentication using only kerberos, I have no use for pam-ldap, right ?
<6> right
<13> Great, thanks!
<6> although in general, if you're using Kerberos, you shouldn't be using PAM at all.
Return to
#ldap
or
Go to some related
logs:
#web
xorg x1600
gentoo+sparc+raid5
debian unstable netinstall iso
speedstepping gnome amd64
#sed
sed literal new line
+madwifi +Failed dependencies +suse 10.1
locsmif hacker
#osdev
|
|