Re: LDIF case sensitivity, login_ldap
On Thu, 2022-06-09 at 07:48 +, Stuart Henderson wrote:
> On 2022-06-09, David Diggles wrote:
> > I've just got ldap login working on OpenBSD/7.1 with accounts stored
> > locally in ldapd and using ypldap.
> >
> > I just thought I'd share something so anyone reading this may save
> > wasting the time that I wasted :-)
> >
> > Your LDIF entry that you read into ldap must be as follows for
> > userPassword
> >
> > userPassword: {CRYPT}${ENCRYPTED_PASSWD}
> >
> > ie uppercase CRYPT - I was stuffing around for ages with trying to
> > understand why login_ldap was failing to bind because I had {crypt} in
> > lowercase.
>
> Perhaps it would make sense for ldapd to support {crypt} as well..
No personal preference, but seems easy enough at first glance.
Only compile-tested though...
martijn@
Index: auth.c
===
RCS file: /cvs/src/usr.sbin/ldapd/auth.c,v
retrieving revision 1.14
diff -u -p -r1.14 auth.c
--- auth.c 24 Oct 2019 12:39:26 - 1.14
+++ auth.c 9 Jun 2022 11:23:06 -
@@ -220,7 +220,7 @@ check_password(struct request *req, cons
if (stored_passwd == NULL)
return -1;
- if (strncmp(stored_passwd, "{SHA}", 5) == 0) {
+ if (strncasecmp(stored_passwd, "{SHA}", 5) == 0) {
sz = b64_pton(stored_passwd + 5, tmp, sizeof(tmp));
if (sz != SHA_DIGEST_LENGTH)
return (-1);
@@ -228,7 +228,7 @@ check_password(struct request *req, cons
SHA1_Update(, passwd, strlen(passwd));
SHA1_Final(md, );
return (bcmp(md, tmp, SHA_DIGEST_LENGTH) == 0 ? 1 : 0);
- } else if (strncmp(stored_passwd, "{SSHA}", 6) == 0) {
+ } else if (strncasecmp(stored_passwd, "{SSHA}", 6) == 0) {
sz = b64_pton(stored_passwd + 6, tmp, sizeof(tmp));
if (sz <= SHA_DIGEST_LENGTH)
return (-1);
@@ -238,12 +238,12 @@ check_password(struct request *req, cons
SHA1_Update(, salt, sz - SHA_DIGEST_LENGTH);
SHA1_Final(md, );
return (bcmp(md, tmp, SHA_DIGEST_LENGTH) == 0 ? 1 : 0);
- } else if (strncmp(stored_passwd, "{CRYPT}", 7) == 0) {
+ } else if (strncasecmp(stored_passwd, "{CRYPT}", 7) == 0) {
encpw = crypt(passwd, stored_passwd + 7);
if (encpw == NULL)
return (-1);
return (strcmp(encpw, stored_passwd + 7) == 0 ? 1 : 0);
- } else if (strncmp(stored_passwd, "{BSDAUTH}", 9) == 0) {
+ } else if (strncasecmp(stored_passwd, "{BSDAUTH}", 9) == 0) {
if (send_auth_request(req, stored_passwd + 9, passwd) == -1)
return (-1);
return 2; /* Operation in progress. */
Re: LDIF case sensitivity, login_ldap
On 2022-06-09, David Diggles wrote:
> I've just got ldap login working on OpenBSD/7.1 with accounts stored
> locally in ldapd and using ypldap.
>
> I just thought I'd share something so anyone reading this may save
> wasting the time that I wasted :-)
>
> Your LDIF entry that you read into ldap must be as follows for
> userPassword
>
> userPassword: {CRYPT}${ENCRYPTED_PASSWD}
>
> ie uppercase CRYPT - I was stuffing around for ages with trying to
> understand why login_ldap was failing to bind because I had {crypt} in
> lowercase.
Perhaps it would make sense for ldapd to support {crypt} as well..
> If you search the interwebs you'll find many complicated examples for
> the ldap class in login.conf but the following worked fine for this
> local setup:
>
> # /etc/login.conf.d/ldap
>
> ldap:\
> :auth=ldap:\
> :x-ldap-uscope=subtree:\
> :tc=default:
"auth=ldap" (rather than "auth=-ldap") suggests you're using login_ldap
from the base OS, but that uses /etc/login_ldap.conf for settings so
presence of x-ldap-uscope suggests you're using login_ldap from ports.
The ports version has been left around partly because configuration is
different and it would suck if you can't login to fix it, and partly in
case anyone was actually needing the features that were dropped when it
was rewritten for the base OS.
It would be a good idea to use the base OS version as there's less risk
of it getting out of sync following uodates. And if you used the ports
one and *copied* it over /usr/libexec/auth/login_ldap you definitely
want to fix that.
Re: login_ldap
On Wed, Mar 28, 2007 at 12:45:04PM -0400, Mike Erdely wrote:
What I've decided to do since I can't make this work ('cause I'm an
idiot) and pserver is insecure and sucks, I'm going to set local
passwords for users that require pserver that are different from their
LDAP password. That way, their LDAP password won't go in the clear.
Just another thought I had 1/2 a second after hitting 'send'...
Maybe SSH tunneling and/or authpf is useful here? You could get fancy
with a full VPN - IPsec is well-supported by OpenBSD, and can be made to
work on other systems, and OpenVPN is easy to install - but forwarding
2401/tcp most likely suffices.
Joachim
Re: login_ldap
On Wed, Mar 28, 2007 at 12:45:04PM -0400, Mike Erdely wrote:
Joachim Schipper wrote:
On Tue, Mar 27, 2007 at 04:49:05PM -0400, Mike Erdely wrote:
I'm trying to get login_ldap to work with cvs pserver (run out of inetd).
I think you are misunderstanding some things, or doing something that
doesn't work; however, since I've never tried to set up a pserver, you'd
best check what I'm going to say next.
I tried to give as much info as I could...
First, read login.conf(5), and note that just adding the above isn't
going to help any. You must define a new login class, at least, and
change master.passwd(5) to make sure the appropriate user has your newly
defined login class (the value of 'appropriate' depends on whether or
not the stuff below is correct...).
I did read login.conf(5) and I must have missed something. But, I think
you're not understanding how this stuff works:
Quite possibly, hence the above caveat.
1. I installed the login_ldap package.
2. I added a ldap section to login.conf
3. I configured my users to be part of the ldap class (using vipw).
Users have no local password set.
4. I tested using CVS over SSH and it works as expected.
5. I tried using pserver and cannot authenticate.
6. I set a local password that is different from my ldap password (ssh
still uses ldap. sudo still uses ldap).
7. I tried pserver and was able to authenticate with the local password
but not ldap's password.
I had previously had a similar problem with ftp until I made this change
to login.conf:
- auth-ftp-defaults:auth-ftp=password:
+ auth-ftp-defaults:auth-ftp=-ldap:
Then, you should have whatever daemon your users use to connect with the
usual BSD login mechanism (which might be called bsdauth, or whatever).
I don't believe GNU CVS does that, and OpenCVS doesn't do authentication
at all. Your best bet is probably setting up ssh; sshd uses the BSD
authentication routines by default.
You would think that the daemon would use the usual BSD login
mechanism but ftpd doesn't. And pserver running out of inetd doesn't
either. I don't know if the fact that I'm using inetd for pserver has
any bearing on this issue, but I thought giving all information would be
helpful.
Actually, ftpd does. inetd doesn't do authentication at all, and
pserver... well, see below.
I know my best bet is using ssh. I'd much rather use ssh. But you
can't always do what you want. Some of my 50 developers are using COTS
development tools that ONLY know pserver. They don't like it either,
but it's required for the project they're working on. So, while pserver
sucks, it's necessary in this case.
However, unless I am sorely mistaken, by this point, there's no need to
set up inetd and what you have is a CVS repository, but *not* a pserver.
What I've decided to do since I can't make this work ('cause I'm an
idiot) and pserver is insecure and sucks, I'm going to set local
passwords for users that require pserver that are different from their
LDAP password. That way, their LDAP password won't go in the clear.
That is a good solution. The problem is, in fact, rather simple: pserver
does, in fact, not use bsd authentication. This is documented in
http://ximbiot.com/cvs/manual/cvs-1.12.13/cvs_2.html#SEC31 and
elsewhere; however, that page also suggests that you could create a
custom password file. Maybe a small script is in order (get 'cvspass'
from LDAP, format text file, mv it over the old one, repeat every x
minutes)?
Anyway, good luck, and let us know if you have any more problems.
Joachim
Re: login_ldap
Joachim Schipper wrote:
On Tue, Mar 27, 2007 at 04:49:05PM -0400, Mike Erdely wrote:
I'm trying to get login_ldap to work with cvs pserver (run out of inetd).
I think you are misunderstanding some things, or doing something that
doesn't work; however, since I've never tried to set up a pserver, you'd
best check what I'm going to say next.
I tried to give as much info as I could...
First, read login.conf(5), and note that just adding the above isn't
going to help any. You must define a new login class, at least, and
change master.passwd(5) to make sure the appropriate user has your newly
defined login class (the value of 'appropriate' depends on whether or
not the stuff below is correct...).
I did read login.conf(5) and I must have missed something. But, I think
you're not understanding how this stuff works:
1. I installed the login_ldap package.
2. I added a ldap section to login.conf
3. I configured my users to be part of the ldap class (using vipw).
Users have no local password set.
4. I tested using CVS over SSH and it works as expected.
5. I tried using pserver and cannot authenticate.
6. I set a local password that is different from my ldap password (ssh
still uses ldap. sudo still uses ldap).
7. I tried pserver and was able to authenticate with the local password
but not ldap's password.
I had previously had a similar problem with ftp until I made this change
to login.conf:
- auth-ftp-defaults:auth-ftp=password:
+ auth-ftp-defaults:auth-ftp=-ldap:
Then, you should have whatever daemon your users use to connect with the
usual BSD login mechanism (which might be called bsdauth, or whatever).
I don't believe GNU CVS does that, and OpenCVS doesn't do authentication
at all. Your best bet is probably setting up ssh; sshd uses the BSD
authentication routines by default.
You would think that the daemon would use the usual BSD login
mechanism but ftpd doesn't. And pserver running out of inetd doesn't
either. I don't know if the fact that I'm using inetd for pserver has
any bearing on this issue, but I thought giving all information would be
helpful.
I know my best bet is using ssh. I'd much rather use ssh. But you
can't always do what you want. Some of my 50 developers are using COTS
development tools that ONLY know pserver. They don't like it either,
but it's required for the project they're working on. So, while pserver
sucks, it's necessary in this case.
However, unless I am sorely mistaken, by this point, there's no need to
set up inetd and what you have is a CVS repository, but *not* a pserver.
What I've decided to do since I can't make this work ('cause I'm an
idiot) and pserver is insecure and sucks, I'm going to set local
passwords for users that require pserver that are different from their
LDAP password. That way, their LDAP password won't go in the clear.
Thanks for you input.
-ME
Re: login_ldap
On Wednesday 28 March 2007 11:45, Mike Erdely wrote:
Joachim Schipper wrote:
On Tue, Mar 27, 2007 at 04:49:05PM -0400, Mike Erdely wrote:
I'm trying to get login_ldap to work with cvs pserver (run out of
inetd).
I think you are misunderstanding some things, or doing something
that doesn't work; however, since I've never tried to set up a
pserver, you'd best check what I'm going to say next.
I tried to give as much info as I could...
First, read login.conf(5), and note that just adding the above
isn't going to help any. You must define a new login class, at
least, and change master.passwd(5) to make sure the appropriate
user has your newly defined login class (the value of 'appropriate'
depends on whether or not the stuff below is correct...).
I did read login.conf(5) and I must have missed something. But, I
think you're not understanding how this stuff works:
1. I installed the login_ldap package.
2. I added a ldap section to login.conf
3. I configured my users to be part of the ldap class (using vipw).
Users have no local password set.
4. I tested using CVS over SSH and it works as expected.
5. I tried using pserver and cannot authenticate.
6. I set a local password that is different from my ldap password
(ssh still uses ldap. sudo still uses ldap).
7. I tried pserver and was able to authenticate with the local
password but not ldap's password.
I use login_ldap but don't have any experience with cvs pserver. Just in
case it has any relevance or triggers some other solution . . .
1) Are you using LDAPv2 or LDAPv3? If you are using v3, you may want to
try v2.
2) What does /var/log/ldap.log say about authentication attempts?
Vijay
I had previously had a similar problem with ftp until I made this
change to login.conf:
- auth-ftp-defaults:auth-ftp=password:
+ auth-ftp-defaults:auth-ftp=-ldap:
Then, you should have whatever daemon your users use to connect
with the usual BSD login mechanism (which might be called bsdauth,
or whatever). I don't believe GNU CVS does that, and OpenCVS
doesn't do authentication at all. Your best bet is probably setting
up ssh; sshd uses the BSD authentication routines by default.
You would think that the daemon would use the usual BSD login
mechanism but ftpd doesn't. And pserver running out of inetd
doesn't either. I don't know if the fact that I'm using inetd for
pserver has any bearing on this issue, but I thought giving all
information would be helpful.
I know my best bet is using ssh. I'd much rather use ssh. But you
can't always do what you want. Some of my 50 developers are using
COTS development tools that ONLY know pserver. They don't like it
either, but it's required for the project they're working on. So,
while pserver sucks, it's necessary in this case.
However, unless I am sorely mistaken, by this point, there's no
need to set up inetd and what you have is a CVS repository, but
*not* a pserver.
What I've decided to do since I can't make this work ('cause I'm an
idiot) and pserver is insecure and sucks, I'm going to set local
passwords for users that require pserver that are different from
their LDAP password. That way, their LDAP password won't go in the
clear.
Thanks for you input.
-ME
!DSPAM:1,460aa359109502517112723!
--
Vijay Sankar
ForeTell Technologies Limited
59 Flamingo Avenue, Winnipeg, MB, Canada R3J 0X6
Phone: +1 (204) 885-9535, E-Mail: [EMAIL PROTECTED]
Re: login_ldap
Vijay Sankar wrote: I use login_ldap but don't have any experience with cvs pserver. Just in case it has any relevance or triggers some other solution . . . 1) Are you using LDAPv2 or LDAPv3? If you are using v3, you may want to try v2. I'm using the default in login.conf for login_ldap, which is to use v3. 2) What does /var/log/ldap.log say about authentication attempts? I assume this would be on an OpenLDAP server and not the CVS/login_ldap client. I'm using blush / MS AD as the LDAP server. Remember, ssh, cvs over ssh and sudo work great with my login.conf ldap user class. It feels like pserver is not respecting that authentication method. Vijay !DSPAM:1,460aa359109502517112723!
login_ldap
I'm trying to get login_ldap to work with cvs pserver (run out of inetd). Regular SSH logins work fine. I know to make ftpd work with login_ldap, you have to make the following change in login.conf: - auth-ftp-defaults:auth-ftp=password: + auth-ftp-defaults:auth-ftp=-ldap: For trying to make pserver work, I _tried_ adding auth-pserver-defaults:auth-pserver=-ldap: to login.conf and :tc=auth-pserver-defaults:\ to the default section in login.conf. I still can't login to pserver with my LDAP password. If I change my local password from no password to some password, I can login so pserver is working. Anyone know how to make pserver work with login_ldap? Thanks. -ME
Re: login_ldap
On Tue, Mar 27, 2007 at 04:49:05PM -0400, Mike Erdely wrote: I'm trying to get login_ldap to work with cvs pserver (run out of inetd). Regular SSH logins work fine. I know to make ftpd work with login_ldap, you have to make the following change in login.conf: - auth-ftp-defaults:auth-ftp=password: + auth-ftp-defaults:auth-ftp=-ldap: For trying to make pserver work, I _tried_ adding auth-pserver-defaults:auth-pserver=-ldap: to login.conf and :tc=auth-pserver-defaults:\ to the default section in login.conf. I still can't login to pserver with my LDAP password. If I change my local password from no password to some password, I can login so pserver is working. Anyone know how to make pserver work with login_ldap? I think you are misunderstanding some things, or doing something that doesn't work; however, since I've never tried to set up a pserver, you'd best check what I'm going to say next. First, read login.conf(5), and note that just adding the above isn't going to help any. You must define a new login class, at least, and change master.passwd(5) to make sure the appropriate user has your newly defined login class (the value of 'appropriate' depends on whether or not the stuff below is correct...). Then, you should have whatever daemon your users use to connect with the usual BSD login mechanism (which might be called bsdauth, or whatever). I don't believe GNU CVS does that, and OpenCVS doesn't do authentication at all. Your best bet is probably setting up ssh; sshd uses the BSD authentication routines by default. However, unless I am sorely mistaken, by this point, there's no need to set up inetd and what you have is a CVS repository, but *not* a pserver. Joachim
Re: login_ldap
On Wed, Mar 28, 2007 at 01:19:05AM +0200, Joachim Schipper wrote: I don't believe GNU CVS does that, and OpenCVS doesn't do authentication at all. Your best bet is probably setting up ssh; sshd uses the BSD authentication routines by default. More specifically, OpenCVS doesn't do pserver at all. Pserver is crud -- even the original authors will admit this if you ask them.
Re: skeyinit and lock - login class data unavailable (side effect of login_ldap permissions for login.conf)
In message [EMAIL PROTECTED] so spake Rogier Krieger (rkrieger): Is there a way to open up login.conf without divulging the bindpw? Reading the login_ldap and login.conf man pages, I did not find any. So far, I see two possible remedies: [1] patching login_ldap to obtain sensitive data in a similar way as login_radius does from /etc/raddb or [2] make /etc/login.conf readable to the 'auth' group, as both lock and skeyinit have their SGID bits set. Since [2] is less intrusive, I am inclined to take that route. Are there any setbacks to expect? Other suggestions are more than welcome, of course. I would suggest you go with [2]. There shouldn't be any real downside. - todd
login_ldap and /etc/passwd sync
Hi all, Anybody out there is working with this scenery? (cron activated, no need for real time). I don't want to use YP just for this and I see a lot a people in linux world using scripts for remote ldap sync. But I have not found any obsd specific experience. Regads.
Re: login_ldap
One more problem I have with login_ldap is that after I lock KDE with the blue lock-applet (kdesktop_lock), then I can't login anymore. The /var/log/authlog: Aug 8 13:52:43 blowfish kcheckpass[7059]: Authentication failure for afarber (invoked by uid 25323) I've searched around and one workaround mentioned is to make kcheckpass setuid. But this is actually the case with the stock 3.7 KDE-package, so this doesn't help 24 -rwsr-xr-x 1 root bin 11108 Mar 18 10:55 /usr/local/bin/kcheckpass Regards Alex 2005/8/4, Alexander Farber [EMAIL PROTECTED]: blowfish# tail /etc/login.conf ldap:\ :auth=-ldap:\ :x-ldap-server=172.25.93.242:\ :x-ldap-basedn=o=bonmp.XXX.com:\ :x-ldap-uscope=subtree:\ :x-ldap-filter=(uid=%u): blowfish# /usr/local/libexec/auth/login_-ldap -d afarber ldap Password: uri = ldap://172.25.93.242:389/ filter = (uid=afarber) search result 0x0 authorize Now my problem is, that for every user there needs to be an entry in /etc/passwd (is it needed for setting the login class to ldap?). And we have 200-300 users at our site (and much more globally). I wonder, how do the others handle this case of many users?
Re: login_ldap
Alexander Farber wrote: One more problem I have with login_ldap is that after I lock KDE with the blue lock-applet (kdesktop_lock), then I can't login anymore. The /var/log/authlog: Aug 8 13:52:43 blowfish kcheckpass[7059]: Authentication failure for afarber (invoked by uid 25323) My users under kerberos have the same problem. The thing is that KDE does not support bsd_auth. Antoine
Re: login_ldap
On Thu, Aug 04, 2005 at 09:43:28AM +0200, Alexander Farber wrote: Also, does anybody know, how to run /usr/local/libexec/auth/login_-ldap on a command line, to see if it works at all? I try following: blowfish# /usr/local/libexec/auth/login_-ldap afarber blowfish# echo $? 1 Eyeing the code it looks like: /usr/libexec/auth/login_-ldap -d afarber should be more verbose.
Re: login_ldap
2005/8/4, John Wright [EMAIL PROTECTED]: /usr/libexec/auth/login_-ldap -d afarber should be more verbose. Thank you, now I get: blowfish# /usr/local/libexec/auth/login_-ldap -d afarber Password: couldn't get x-ldap-server reject Aug 4 10:11:43 blowfish login_-ldap: couldn't get x-ldap-server Aug 4 10:11:43 blowfish login_-ldap: couldn't get x-ldap-server I tried to look into login_ldap.c too and understood that it probably didn't get my class correctly (wasn't it supposed to know it is ldap - from my /etc/passwd entry?). So now I specify the class too and get: blowfish# /usr/local/libexec/auth/login_-ldap -d afarber ldap Password: uri = ldap://172.25.93.242:389/ filter = (uid=afarber) search result 0x0 reject What does it mean, is my filter maybe wrong? What LDAP-fields is login_-ldap looking at? Regards Alex PS: I paste my /etc/login.conf below, but actually only the last 6 lines were added by me to the stock version: # $OpenBSD: login.conf,v 1.19 2005/02/07 08:33:05 otto Exp $ # # Sample login.conf file. See login.conf(5) for details. # # # Standard authentication styles: # # krb5-or-pwd First try Kerberos V password, then local password file # passwdUse only the local password file # krb5 Use only the Kerberos V password # chpassDo not authenticate, but change users password (change # the kerberos password if the user has one, else change # the local password) # lchpass Do not login; change user's local password instead # radiusUse radius authentication # skey Use S/Key authentication # activ ActivCard X9.9 token authentication # cryptoCRYPTOCard X9.9 token authentication # snk Digital Pathways SecureNet Key authentication # token Generic X9.9 token authentication # # Default allowed authentication styles # useradd -m -d /home/afarber -s /usr/local/bin/tcsh -L ldap afarber # auth-defaults:auth=-ldap,passwd,skey: auth-defaults:auth=passwd,skey: # Default allowed authentication styles for authentication type ftp auth-ftp-defaults:auth-ftp=passwd: # # The default values # To alter the default authentication types change the line: # :tc=auth-defaults:\ # to be read something like: (enables passwd, myauth, and activ) # :auth=passwd,myauth,activ:\ # Any value changed in the daemon class should be reset in default # class. # default:\ :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin:\ :umask=022:\ :datasize-max=256M:\ :datasize-cur=75M:\ :maxproc-max=128:\ :maxproc-cur=64:\ :openfiles-cur=64:\ :stacksize-cur=4M:\ :localcipher=blowfish,6:\ :ypcipher=old:\ :tc=auth-defaults:\ :tc=auth-ftp-defaults: # # Settings used by /etc/rc and root # This must be set properly for daemons started as root by inetd as well. # Be sure reset these values back to system defaults in the default class! # daemon:\ :ignorenologin:\ :datasize=infinity:\ :maxproc=infinity:\ :openfiles-cur=128:\ :stacksize-cur=8M:\ :localcipher=blowfish,8:\ :tc=default: # # Staff have fewer restrictions and can login even when nologins are set. # staff:\ :datasize-cur=75M:\ :datasize-max=infinity:\ :maxproc-max=256:\ :maxproc-cur=128:\ :ignorenologin:\ :requirehome@:\ :tc=default: # XXX ldap:\ :auth=-ldap:\ :x-ldap-server=172.25.93.242:\ :x-ldap-basedn=o=bonmp.XXX.com:\ :x-ldap-filter=(uid=%u): [demime 1.01d removed an attachment of type application/octet-stream which had a name of login.conf]
Re: login_ldap
Here is what I get on the command line (a result: 0 Success, so I wonder why does login_-ldap fail?) blowfish# ldapsearch -x -h 172.25.93.242 \ -b o=bonmp.XXX.com (uid=afarber) # extended LDIF # # LDAPv3 # base o=bonmp.XXX.com with scope sub # filter: (uid=afarber) # requesting: ALL # # afarber, People, bonmp.XXX.com dn: uid=afarber,ou=People,o=bonmp.XXX.com shadowLastChange: 12947 userPassword:: e2NyeXB0fXXkMW1xaDkxSUo2OEE= gidNumber: 5525 mail: [EMAIL PROTECTED] loginShell: /bin/tcsh employeeNumber: 20164153 shadowFlag: 0 uid: afarber cn: Alexander Farber objectClass: top objectClass: account objectClass: posixAccount objectClass: XXXperson objectClass: shadowAccount uidNumber: 22323 homeDirectory: /home/afarber gecos: Alexander Farber,joined-0X/0X,No_Number,,,[EMAIL PROTECTED] # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 2005/8/4, Alexander Farber [EMAIL PROTECTED]: blowfish# /usr/local/libexec/auth/login_-ldap -d afarber ldap Password: uri = ldap://172.25.93.242:389/ filter = (uid=afarber) search result 0x0 reject # $OpenBSD: login.conf,v 1.19 2005/02/07 08:33:05 otto Exp $ ldap:\ :auth=-ldap:\ :x-ldap-server=172.25.93.242:\ :x-ldap-basedn=o=bonmp.XXX.com:\ :x-ldap-filter=(uid=%u):
Re: login_ldap
2005/8/4, John Wright [EMAIL PROTECTED]: On Thu, Aug 04, 2005 at 10:47:00AM +0200, Alexander Farber wrote: # base o=bonmp.XXX.com with scope sub Maybe the scope? If I'm reading the code correctly the default is onelevel (or -s one on the ldapsearch command line) but the default for ldapsearch is subtree. Ahh, that was it. Thank you, now I can login blowfish# tail /etc/login.conf ldap:\ :auth=-ldap:\ :x-ldap-server=172.25.93.242:\ :x-ldap-basedn=o=bonmp.XXX.com:\ :x-ldap-uscope=subtree:\ :x-ldap-filter=(uid=%u): blowfish# /usr/local/libexec/auth/login_-ldap -d afarber ldap Password: uri = ldap://172.25.93.242:389/ filter = (uid=afarber) search result 0x0 authorize Now my problem is, that for every user there needs to be an entry in /etc/passwd (is it needed for setting the login class to ldap?). And we have 200-300 users at our site (and much more globally). I wonder, how do the others handle this case of many users? Regards Alex
