We've had two problems with concurrent login checking that I wanted to run
by everyone.  We're running 2.13.1 on a mix of Solaris 2.5.1 and Solaris 7
boxes; we have the snmpget from UCD SNMP (v3.6).  Please pardon my ignorance
on some of the Radiator configuration options; I haven't actually been
doing the configuration but am sending this on behalf of the people who
have.

We originally had MaxSessions enabled, but it appeared to be having no
effect.  Below are the (hopefully) relevant parts of the config file.
We don't use an external session database, BTW.

LogDir /var/adm/radacct
DbDir /etc/raddb
SnmpgetProg /usr/local/bin/snmpget
...
<Client xxx.xxx.xxx.xxx>
         Secret  <not shown>
         NasType Livingston
         SNMPCommunity <not shown>
         DupInterval 300
</Client>
...
<Realm>
       <AuthBy FILE>
       </AuthBy>
        AcctLogFileName %L/%N/detail
</Realm>
<Realm DEFAULT>
       MaxSessions 1
       <AuthBy UNIX>
         Identifier System
         Filename /etc/shadow
       </AuthBy>
       AcctLogFileName %L/%N/detail
</Realm>

When someone connected via the NAS and we then ran radpwtst for that same
userid, the radpwtst authentication was accepted (OK).  We had trace 4
enabled and didn't see any output related to snmp or checking for multiple
connections; I'm including some of the debug output (accounting info
trimmed for brevity) below.

First connection (on the NAS):
Wed Oct 13 14:49:20 1999: DEBUG: Handling request with Handler 'Realm='
Wed Oct 13 14:49:20 1999: DEBUG: Handling with Radius::AuthFILE
Wed Oct 13 14:49:20 1999: DEBUG: Radius::AuthFILE looks for match with testuser
Wed Oct 13 14:49:20 1999: DEBUG: Radius::AuthFILE looks for match with DEFAULT
Wed Oct 13 14:49:20 1999: DEBUG: Handling with Radius::AuthUNIX
Wed Oct 13 14:49:20 1999: DEBUG: Radius::AuthUNIX looks for match with testuser
Wed Oct 13 14:49:20 1999: DEBUG: Radius::AuthUNIX ACCEPT:
Wed Oct 13 14:49:20 1999: DEBUG: Radius::AuthFILE ACCEPT:
Wed Oct 13 14:49:20 1999: DEBUG: Access accepted for testuser

Second connection (via radpwtst):
Wed Oct 13 14:50:26 1999: DEBUG: Handling request with Handler 'Realm='
Wed Oct 13 14:50:26 1999: DEBUG: Handling with Radius::AuthFILE
Wed Oct 13 14:50:26 1999: DEBUG: Radius::AuthFILE looks for match with testuser
Wed Oct 13 14:50:26 1999: DEBUG: Radius::AuthFILE looks for match with DEFAULT
Wed Oct 13 14:50:26 1999: DEBUG: Handling with Radius::AuthUNIX
Wed Oct 13 14:50:26 1999: DEBUG: Radius::AuthUNIX looks for match with testuser
Wed Oct 13 14:50:26 1999: DEBUG: Radius::AuthUNIX ACCEPT:
Wed Oct 13 14:50:26 1999: DEBUG: Radius::AuthFILE ACCEPT:
Wed Oct 13 14:50:26 1999: DEBUG: Access accepted for testuser

Since that didn't appear to be working, Simultaneous-Use=1 was added to
the DEFAULT user in the users file, as shown below.

DEFAULT Auth-Type = System, NAS-Port-Type = Async, Simultaneous-Use = 1
         Service-Type = Framed-User,
         Framed-Protocol = PPP,
         Framed-Address = 255.255.255.254,
         Framed-Netmask = 255.255.255.255,
         Reply-Message="choice: ",
         Port-Limit = 1,
         Idle-Timeout = 1200,
         Session-Timeout = 28800

During initial testing, that did appear to enable the concurrent login
checking and didn't appear to affect anyone who was making an initial
connection (not already online).  Then reports started coming in of users
who were not able to connect at all, even when not already online.  Not
every user, of course, just some users.  Helps a lot, right? :-)  All of
the userids (both the unaffected and affected) were hitting the DEFAULT
users entry, which hits against the system shadow file.

We checked through the detail files for a few of the userids that had
reported problems and couldn't find any trace of the userids being active
at the time their access was denied.  We also looked for duplicate session
IDs, but didn't find any of those.  All of the users we checked did have
Stop records for their previous Start records.

We're going to try it again tomorrow with Radiator in debug mode and only
one location hitting that server, but wanted to see if anyone noticed
something obviously wrong with our configuration or had any recommendations.
Thank you for your time!

Dawn Lovell
[EMAIL PROTECTED]

===
Archive at http://www.thesite.com.au/~radiator/
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.

Reply via email to