Hi Alan... This is what I'm getting.... rad_recv: Access-Request packet from host 10.66.64.41:1645, id=140, length=78 NAS-IP-Address = 10.66.64.41 NAS-Port = 37 NAS-Port-Type = Async User-Name = "begomez" Calling-Station-Id = "10.66.64.35" User-Password = "junk" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 14 modcall[authorize]: module "preprocess" returns ok for request 14 modcall[authorize]: module "chap" returns noop for request 14 modcall[authorize]: module "mschap" returns noop for request 14 rlm_realm: No '@' in User-Name = "begomez", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 14 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 14 users: Matched entry DEFAULT at line 153 modcall[authorize]: module "files" returns ok for request 14 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 14 modcall: leaving group authorize (returns ok) for request 14 rad_check_password: Found Auth-Type System auth: type "System" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 14 modcall[authenticate]: module "unix" returns notfound for request 14 modcall: leaving group authenticate (returns notfound) for request 14 auth: Failed to validate the user. Delaying request 14 for 1 seconds I'm using the UNIX module (see below). Maybe it's a Solaris issue and not freeradius. unix { # # Cache /etc/passwd, /etc/shadow, and /etc/group # # The default is to NOT cache them. # # For FreeBSD and NetBSD, you do NOT want to enable # the cache, as it's password lookups are done via a # database, so set this value to 'no'. # # Some systems (e.g. RedHat Linux with pam_pwbd) can # take *seconds* to check a password, when th passwd # file containing 1000's of entries. For those systems, # you should set the cache value to 'yes', and set # the locations of the 'passwd', 'shadow', and 'group' # files, below. # # allowed values: {no, yes} cache = no # Reload the cache every 600 seconds (10mins). 0 to disable. cache_reload = 600 # # Define the locations of the normal passwd, shadow, and # group files. # # 'shadow' is commented out by default, because not all # systems have shadow passwords. # # To force the module to use the system password functions, # instead of reading the files, leave the following entries # commented out. # # This is required for some systems, like FreeBSD, # and Mac OSX. # passwd = /export/home1/cms/passwd # shadow = /etc/shadow # group = /etc/group # # The location of the "wtmp" file. # This should be moved to it's own module soon. # # The only use for 'radlast'. If you don't use # 'radlast', then you can comment out this item. # radwtmp = ${logdir}/radwtmp } What ya think????/ Frank ------------------------------------------------------------ | | Frank Everitt | | Systems Administrator :|||: :|||: 7025 Kit Creek Rd. :|||||: :|||||: RTP, NC 27709 ..:|||||||:.....:|||||||:.... Ph :(919) 392-8885 FAX :(469) 574-5042 CISCO SYSTEMS Cell:(919) 624-6098 ------------------------------------------------------------ On Nov 27, 2007, at 2:34 PM, Alan DeKok wrote:
Frank Everitt wrote:
I'm running Freeradius 1.1.6 on a Solaris 10 platform and have run across a strange problem. My password file contains over 80 thousands entries and it appears that freeradius won't find a user entry beyond line 76665. Is there a buffer that can be bumped up or have I just reached a limitation of using the UNIX style password file within radiusd?
Is the password being fetched from the "unix" module, or the "passwd" module? If it's "passwd", switch to "unix". If it's "unix", then FreeRADIUS just does 'getpwent', and it's up to the system libraries to return the right entry.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ users.html