Hi all, I am trying to upgrade from an ancient 1.0.5 to 2.1.0, and ran into trouble where I least expected it. Underneath is Debian Lenny system run as Linux vserver.
I have a large set of users handled by LDAP, and a small group (admins with only a few logins) that I used to handle by setting up a bunch of local unix accounts and doing Auth-Type := System. So my users file looks like pauly Auth-Type := System, Calling-Station-Id =~ "our-special-id-prefix" Reply-Message = "Matched local user entry %{User-Name} in users file", [ more local accounts ...] DEFAULT Auth-Type := Reject, Calling-Station-Id =~ "our-special-id-prefix" Reply-Message = "Illegal username %{User-Name} for this type of request" DEFAULT User-Name = `%{User-Name}`, Reply-Message = "Matched DEFAULT user entry with User-Name %{User-Name}" In sites-available/default, I have 'unix' in both the authorize and authenticate section. The debug output upon a request reads: rad_recv: Access-Request packet from host 192.168.x.y port 1645, id=204, length=77 NAS-IP-Address = 192.168.x.y NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "pauly" Calling-Station-Id = "our-special-id" User-Password = "xxxxxx" +- entering group authorize {...} ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop [suffix] No '@' in User-Name = "pauly", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[unix] returns notfound expand: %{Calling-Station-Id} -> our-special-id [files] users: Matched entry pauly at line 17 expand: Matched local user entry %{User-Name} in users file -> Matched local user entry pauly in users file ++[files] returns ok [ the whole thing is sent to LDAP for authorization now which succeeds, but could perhaps be avoided anyway] ++- entering policy redundant {...} [ldap stuff ...] [ldap2] user pauly authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 +++[ldap2] returns ok ++- policy redundant returns ok ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop Found Auth-Type = System +- entering group authenticate {...} ++[unix] returns notfound Failed to authenticate the user. Using Post-Auth-Type Reject +- entering group REJECT {...} expand: %{User-Name} -> pauly attr_filter: Matched entry DEFAULT at line 11 So to me it looks like rlm_unix can't find me :-( I've read about rlm_passwd, but I don't need any caching or the like. Oh, and user freerad is in group shadow. But as I understand it, this is no longer relevant for my case since rlm_unix uses getpwent which is supposed to handle access to /etc/shadow, right? Thanks for any hint Martin -- Dr. Martin Pauly Fax: 49-6421-28-26994 HRZ Univ. Marburg Phone: 49-6421-28-23527 Hans-Meerwein-Str. E-Mail: [EMAIL PROTECTED] D-35032 Marburg - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html