[RADIATOR] RADIATOR: EAP-FAST-MSCHAPv2
Hi, As I am verifying EAP-FAST which uses inner authentication as MSCHAPv2, for this our device requires any certificates like client certificates? I red that it requires PAC means pac key should match from both sides like radius sever and our device? Thanks Sudhir Larsen Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] RADIATOR: EAP-FAST-MSCHAPv2
On 04/05/2012 10:15 AM, Sudhir Harwalkar wrote: Hello Sudhir, As I am verifying EAP-FAST which uses inner authentication as MSCHAPv2, for this our device requires any certificates like client certificates? I red that it requires PAC means pac key should match from both sides like radius sever and our device? If the client does not send its PAC, Radiator will try to allocate one to it. Then client is then disconnected. Next time when the client tries to authenticate, it will have a PAC and the authentication should then proceed. By default Radiator keeps the PACs in memory with the other option being SQL. So do not restart Radiator unless you want to clear the PAC. Thanks! Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
On 04/03/2012 07:45 PM, Karl Gaissmaier wrote: Hello Charly, I've a problem with AuthBy RADSEC and the failure algorithm. In the eduroam confederation it's nearly impossible to find proper values for NoreplyTimeout, MaxFailedRequests, ... for Access-Requests. It takes sometimes many seconds (till 60s or more) to get an reply for an Access-Request. It would be much better to use Status-Requests against the server to determine if the next server is dead and not an timeout for proxied Access-Requests down the lane. So Status-Server would be used instead of NoReplyTimeout and MaxFailedRequests? If Status-Server gets no response, then the server would be probed infrequently to see when it gets back. Meanwhile the requests would be forwarded to the secondary server? Would the current behaviour of returning nothing (IGNORE) to the previous server still be fine? Another alternative would be to synthesise an Access-Reject to the previous server. Related to this, what is the current view of using Dead Realm Marking in eduroam? http://wiki.eduroam.cz/dead-realm/docs/dead-realm.html If there are more than one next hop server, DRM can try all next hop servers to see if the realm's server(s) are reachable. Has the possibility of trying alternative paths found to be not useful in real life. In other words, if a request for a certain realm times out, is there any use for trying other servers? If nothing is returned, then DRM could try alternative paths. If an Access-Reject is synthesised, then DRM could not be used since the timeouts and real rejects would look the same. Is this a new RFE? How is this solved in other eduroam sites with RADIATOR? Comments would be appreciated. Thanks! Heikki Best Regards and thanks for RADIATOR, the best software I've ever bought! Charly -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
Hi Heikki, thanks for your fast reply! The radiator team is great! Am 05.04.2012 14:00, schrieb Heikki Vatiainen: On 04/03/2012 07:45 PM, Karl Gaissmaier wrote: Hello Charly, I've a problem with AuthBy RADSEC and the failure algorithm. In the eduroam confederation it's nearly impossible to find proper values for NoreplyTimeout, MaxFailedRequests, ... for Access-Requests. It takes sometimes many seconds (till 60s or more) to get an reply for an Access-Request. It would be much better to use Status-Requests against the server to determine if the next server is dead and not an timeout for proxied Access-Requests down the lane. So Status-Server would be used instead of NoReplyTimeout and MaxFailedRequests? If Status-Server gets no response, then the server would be probed infrequently to see when it gets back. Meanwhile the requests would be forwarded to the secondary server? Please see my config chunk: AuthBy RADSEC Hostradius1.dfn.de Hostradius2.dfn.de FailureBackoffTime 2 MaxFailedRequests 1 NoreplyTimeout 45 UseTLS # TLS specific cfg follows /AuthBy I've increased NoreplyTimeout to a big number, since the reply time - Accept or Reject - can't be estimated nor calculated for the whole Radius Server Hops involved in eduroam. If only one organization has a misbehaving radius server with long delays the failure algorithm used with RADIATOR stops all Eduroam proxying from my organization to my up level NREN radius servers, even if they are proper responding. The mistake is, that the NoreplyTimeout is used to determine if the next radius server is down. The NoreplyTimeout says something about the health of the last radius server for this realm, but the failure algo. kills the running connection to my next-hop NREN server. Thats fatal. This failure algorithm is only useful, if the next-hop radius server is at the end in the proxy chain. It is totally useless and harmful in the eduroam radius chain. Would the current behaviour of returning nothing (IGNORE) to the previous server still be fine? Hm, I didn't catch you? My suggestion would be and additional Parameter like CheckServerStatus: AuthBy RADSEC Hostradius1.dfn.de Hostradius2.dfn.de PollServerStatuson # use Server-Status Requests Pollfrequency 5 # any 5s FailureBackoffTime 2 ... /AuthBy Another alternative would be to synthesise an Access-Reject to the previous server. I don't understand what you mean with 'previous server'. Maybe I'm wrong, but the current failure algo is broken for a radius chain and only useful between peers. Related to this, what is the current view of using Dead Realm Marking in eduroam? Maybe it's useful for NREN radius servers and not for universities. And by the way it's the wrong end to solve the problem. We need an algorithm to check the status of the next-hop radius server and not indirect via a reply timeout from a totally different server down the proxy lane. Maybe I can't explain the problem due to my bad english, but please try to solve this problem in correspondence with me, since it's a real problem. Please see in your history, I don't claim often and when I claim it's normally a real world problem. Best Regards Charly -- Karl Gaissmaier Kommunikations und Informationszentrum kiz der Universität Ulm Abteilung Infrastruktur SG Netzwerk und Telekommunikation 89069 Ulm Tel.: 49(0)731/50-22499 Fax : 49(0)731/50-1222499 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] evaluation - Checkby syntax
Hugh, I attempted to use the config provided but the handler is not picking my device up. I have specified to specific IP address instead of DEFAULT, this did not seem to work either. Thu Apr 5 09:09:57 2012: DEBUG: Creating StreamServer tcp port 0.0.0.0:8100 Thu Apr 5 09:09:57 2012: DEBUG: Finished reading configuration file 'simple.cfg' This Radiator license will expire on 2012-08-01 This Radiator license will stop operating after 1000 requests To purchase an unlimited full source version of Radiator, see http://www.open.com.au/ordering.html To extend your license period, contact ad...@open.com.au Thu Apr 5 09:09:57 2012: DEBUG: Reading dictionary file './dictionary' Thu Apr 5 09:09:57 2012: DEBUG: Creating authentication port 0.0.0.0:1812 Thu Apr 5 09:09:57 2012: DEBUG: Creating accounting port 0.0.0.0:1813 Thu Apr 5 09:09:57 2012: NOTICE: Server started: Radiator 4.9 on sec-l-adm02 (LOCKED) Thu Apr 5 09:10:31 2012: DEBUG: Packet dump: *** Received from 10.2.120.150 port 36248 Code: Access-Request Identifier: 185 Authentic: M18A(17_H194B159196?247,ag Attributes: User-Name = robert User-Password = 210J242Q241c^O30185sm2194253 NAS-Port-Id = ttyS0 Service-Type = NAS-Prompt-User NAS-Port = 0 NAS-IP-Address = 10.2.120.150 Thu Apr 5 09:10:31 2012: DEBUG: Handling request with Handler '', Identifier '' Thu Apr 5 09:10:31 2012: DEBUG: Deleting session for robert, 10.2.120.150, 0 Thu Apr 5 09:10:31 2012: DEBUG: Handling with AuthINTERNAL: RejectAuthAcceptAcct Thu Apr 5 09:10:31 2012: DEBUG: AuthBy INTERNAL result: REJECT, Fixed by AuthResult Thu Apr 5 09:10:31 2012: INFO: Access rejected for robert: Fixed by AuthResult Thu Apr 5 09:10:31 2012: DEBUG: Packet dump: *** Sending to 10.2.120.150 port 36248 Code: Access-Reject Identifier: 185 Authentic: g182'A/jRt]53024016027O170 Attributes: Reply-Message = Request Denied Client 10.2.120.150 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client AuthBy SYSTEM Identifier SystemAuthentication /AuthBy AuthBy FILE Identifier GroupAuthentication Filename %D/users /AuthBy AuthBy INTERNAL Identifier RejectAuthAcceptAcct AuthResult REJECT AcctResult ACCEPT /AuthBy Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User AuthByPolicy ContinueWhileAccept AuthBy GroupAuthentication AuthBy SystemAuthentication /Handler Handler AuthBy RejectAuthAcceptAcct /Handler ServerHTTP Port 8100 DefaultPrivilegeLevel 15 /ServerHTTP Robb Pfrank Office +1 (312) 601-8647 r...@headlandstech.com -Original Message- From: Hugh Irvine [mailto:h...@open.com.au] Sent: Tuesday, April 03, 2012 7:24 PM To: Robb Pfrank Cc: radiator@open.com.au Subject: Re: [RADIATOR] evaluation - Checkby syntax Hello Robb - You would do something like the following: SIMPLE.CFG Foreground LogStdout LogDir . DbDir . # User a lower trace level in production systems: Trace 4 AuthPort1645,1812 AcctPort1646,1813 # You will probably want to add other Clients to suit your site, # one for each NAS you want to work with Client 1.1.1.1 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client Client 2.2.2.2 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client Client 3.3.3.3 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client .. AuthBy SYSTEM Identifier SystemAuthentication /AuthBy AuthBy FILE Identifier GroupAuthentication Filename %D/users.group /AuthBy AuthBy INTERNAL Identifier RejectAuthAcceptAcct AuthResult REJECT AcctResult ACCEPT /AuthBy Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User AuthByPolicy ContnueWhileAccept AuthBy GroupAuthentication AuthBy SystemAuthentication /Handler Handler AuthBy RejectAuthAcceptAcct /Handler The contents of the file users.group would look like this: # users.group DEFAULT Auth-Type = SystemAuthentication, Group = netadm BTW - there are a great many example configuration files in the goodies directory of the Radiator distribution. Hope that helps. regards Hugh On 4 Apr 2012, at 05:30, Robb Pfrank wrote: I am evaluating radiator and would like to setup authentication using linux username passwords as well as another type of check to allow access. For instance check if the user is part of a particular group before having their login accepted. Specifically I want to limit networking equipment access to users in the netadm group, I am running this on fedora 12. Below is my simple.cfg for testing, everything else works fine but I am having trouble interpreting the documentation for tiered authentication.
Re: [RADIATOR] evaluation - Checkby syntax
On 04/05/2012 04:12 PM, Robb Pfrank wrote: Hello Robb, I attempted to use the config provided but the handler is not picking my device up. I have specified to specific IP address instead of DEFAULT, this did not seem to work either. Try this: Handler Client-Identifier = NetworkEquipment, Service-Type = NAS-Prompt-User instead of this: Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User Now it fails to match the Handler because Service-Type is different in the request than in the Handler's checklist. Heikki Thu Apr 5 09:09:57 2012: DEBUG: Creating StreamServer tcp port 0.0.0.0:8100 Thu Apr 5 09:09:57 2012: DEBUG: Finished reading configuration file 'simple.cfg' This Radiator license will expire on 2012-08-01 This Radiator license will stop operating after 1000 requests To purchase an unlimited full source version of Radiator, see http://www.open.com.au/ordering.html To extend your license period, contact ad...@open.com.au Thu Apr 5 09:09:57 2012: DEBUG: Reading dictionary file './dictionary' Thu Apr 5 09:09:57 2012: DEBUG: Creating authentication port 0.0.0.0:1812 Thu Apr 5 09:09:57 2012: DEBUG: Creating accounting port 0.0.0.0:1813 Thu Apr 5 09:09:57 2012: NOTICE: Server started: Radiator 4.9 on sec-l-adm02 (LOCKED) Thu Apr 5 09:10:31 2012: DEBUG: Packet dump: *** Received from 10.2.120.150 port 36248 Code: Access-Request Identifier: 185 Authentic: M18A(17_H194B159196?247,ag Attributes: User-Name = robert User-Password = 210J242Q241c^O30185sm2194253 NAS-Port-Id = ttyS0 Service-Type = NAS-Prompt-User NAS-Port = 0 NAS-IP-Address = 10.2.120.150 Thu Apr 5 09:10:31 2012: DEBUG: Handling request with Handler '', Identifier '' Thu Apr 5 09:10:31 2012: DEBUG: Deleting session for robert, 10.2.120.150, 0 Thu Apr 5 09:10:31 2012: DEBUG: Handling with AuthINTERNAL: RejectAuthAcceptAcct Thu Apr 5 09:10:31 2012: DEBUG: AuthBy INTERNAL result: REJECT, Fixed by AuthResult Thu Apr 5 09:10:31 2012: INFO: Access rejected for robert: Fixed by AuthResult Thu Apr 5 09:10:31 2012: DEBUG: Packet dump: *** Sending to 10.2.120.150 port 36248 Code: Access-Reject Identifier: 185 Authentic: g182'A/jRt]53024016027O170 Attributes: Reply-Message = Request Denied Client 10.2.120.150 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client AuthBy SYSTEM Identifier SystemAuthentication /AuthBy AuthBy FILE Identifier GroupAuthentication Filename %D/users /AuthBy AuthBy INTERNAL Identifier RejectAuthAcceptAcct AuthResult REJECT AcctResult ACCEPT /AuthBy Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User AuthByPolicy ContinueWhileAccept AuthBy GroupAuthentication AuthBy SystemAuthentication /Handler Handler AuthBy RejectAuthAcceptAcct /Handler ServerHTTP Port 8100 DefaultPrivilegeLevel 15 /ServerHTTP Robb Pfrank Office +1 (312) 601-8647 r...@headlandstech.com -Original Message- From: Hugh Irvine [mailto:h...@open.com.au] Sent: Tuesday, April 03, 2012 7:24 PM To: Robb Pfrank Cc: radiator@open.com.au Subject: Re: [RADIATOR] evaluation - Checkby syntax Hello Robb - You would do something like the following: SIMPLE.CFG Foreground LogStdout LogDir . DbDir . # User a lower trace level in production systems: Trace 4 AuthPort1645,1812 AcctPort1646,1813 # You will probably want to add other Clients to suit your site, # one for each NAS you want to work with Client 1.1.1.1 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client Client 2.2.2.2 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client Client 3.3.3.3 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client .. AuthBy SYSTEM Identifier SystemAuthentication /AuthBy AuthBy FILE Identifier GroupAuthentication Filename %D/users.group /AuthBy AuthBy INTERNAL Identifier RejectAuthAcceptAcct AuthResult REJECT AcctResult ACCEPT /AuthBy Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User AuthByPolicy ContnueWhileAccept AuthBy GroupAuthentication AuthBy SystemAuthentication /Handler Handler AuthBy RejectAuthAcceptAcct /Handler The contents of the file users.group would look like this: # users.group DEFAULT Auth-Type = SystemAuthentication, Group = netadm BTW - there are a great many example configuration files in the goodies directory of the Radiator distribution. Hope that helps. regards Hugh On 4 Apr 2012, at 05:30, Robb Pfrank wrote: I am
Re: [RADIATOR] RADSEC, failure algorithm, eduroaming and long reply times
On 04/05/2012 04:07 PM, Karl Gaissmaier wrote: Hello Charly, Would the current behaviour of returning nothing (IGNORE) to the previous server still be fine? Hm, I didn't catch you? I was just thinking the case when a request times out and all retries have been tried. Should something sent back (reject) or not. This is related to timeout behaviour, not how polling is done. My suggestion would be and additional Parameter like CheckServerStatus: Thanks for clarifying this. I see what you mean. The interest is not in dead realm marking or determining the reachability of a realm somewhere down the proxy chain, but just the health of next hop. In other words, is radius1.dfn.de responding to Server-Status or not. If not, the radius2.dfn.de should be used. This is how I understand it. AuthBy RADSEC Hostradius1.dfn.de Hostradius2.dfn.de PollServerStatuson # use Server-Status Requests Pollfrequency 5 # any 5s FailureBackoffTime 2 ... /AuthBy Another alternative would be to synthesise an Access-Reject to the previous server. I don't understand what you mean with 'previous server'. Maybe I'm wrong, but the current failure algo is broken for a radius chain and only useful between peers. Previous server would be the one that forwarded the request to your server. Your server is the one that needs to decide if the request should be forwarded to radius1.dfn.de or radius2.dfn.de. What I am thinking if an option to return Access-Reject would be needed when your server sees a timeout while trying to forward the request. In other words, there are two things I am thinking of: 1) Status-Server to poll next hop 2) what to do when a request times out. About 2): Currently nothing is done. If an Access-Reject is returned then at least the server that forwarded us the request (previous server) would see as being alive. If it can use Status-Server, then Access-Reject would not be needed to signal your server is still alive and was not the reason for the timeout. Related to this, what is the current view of using Dead Realm Marking in eduroam? Maybe it's useful for NREN radius servers and not for universities. And by the way it's the wrong end to solve the problem. We need an algorithm to check the status of the next-hop radius server and not indirect via a reply timeout from a totally different server down the proxy lane. Ok. How about using Status-Server to see if the next hop is alive and DRM to try if the destination realm is reachable by some other route? I am trying to get an idea if DRM has been deemed unnecessary in eduroam use. Maybe I can't explain the problem due to my bad english, but please try to solve this problem in correspondence with me, since it's a real problem. Please see in your history, I don't claim often and when I claim it's normally a real world problem. I think I understand what you need. I was just trying to clarify if Status-Server would be enough or if anything else is needed too. Thanks! Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] evaluation - Checkby syntax
Hello Robb - As Heikki rightly says, you will need to alter the Handler definition to match what is actually in the incoming request. It is always essential to study the contents of the incoming requests with a trace 4 debug so you can see exactly what is happening. My example was just that - an example showing how I tend to structure Radiator configuration files. regards Hugh On 6 Apr 2012, at 02:46, Heikki Vatiainen wrote: On 04/05/2012 04:12 PM, Robb Pfrank wrote: Hello Robb, I attempted to use the config provided but the handler is not picking my device up. I have specified to specific IP address instead of DEFAULT, this did not seem to work either. Try this: Handler Client-Identifier = NetworkEquipment, Service-Type = NAS-Prompt-User instead of this: Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User Now it fails to match the Handler because Service-Type is different in the request than in the Handler's checklist. Heikki Thu Apr 5 09:09:57 2012: DEBUG: Creating StreamServer tcp port 0.0.0.0:8100 Thu Apr 5 09:09:57 2012: DEBUG: Finished reading configuration file 'simple.cfg' This Radiator license will expire on 2012-08-01 This Radiator license will stop operating after 1000 requests To purchase an unlimited full source version of Radiator, see http://www.open.com.au/ordering.html To extend your license period, contact ad...@open.com.au Thu Apr 5 09:09:57 2012: DEBUG: Reading dictionary file './dictionary' Thu Apr 5 09:09:57 2012: DEBUG: Creating authentication port 0.0.0.0:1812 Thu Apr 5 09:09:57 2012: DEBUG: Creating accounting port 0.0.0.0:1813 Thu Apr 5 09:09:57 2012: NOTICE: Server started: Radiator 4.9 on sec-l-adm02 (LOCKED) Thu Apr 5 09:10:31 2012: DEBUG: Packet dump: *** Received from 10.2.120.150 port 36248 Code: Access-Request Identifier: 185 Authentic: M18A(17_H194B159196?247,ag Attributes: User-Name = robert User-Password = 210J242Q241c^O30185sm2194253 NAS-Port-Id = ttyS0 Service-Type = NAS-Prompt-User NAS-Port = 0 NAS-IP-Address = 10.2.120.150 Thu Apr 5 09:10:31 2012: DEBUG: Handling request with Handler '', Identifier '' Thu Apr 5 09:10:31 2012: DEBUG: Deleting session for robert, 10.2.120.150, 0 Thu Apr 5 09:10:31 2012: DEBUG: Handling with AuthINTERNAL: RejectAuthAcceptAcct Thu Apr 5 09:10:31 2012: DEBUG: AuthBy INTERNAL result: REJECT, Fixed by AuthResult Thu Apr 5 09:10:31 2012: INFO: Access rejected for robert: Fixed by AuthResult Thu Apr 5 09:10:31 2012: DEBUG: Packet dump: *** Sending to 10.2.120.150 port 36248 Code: Access-Reject Identifier: 185 Authentic: g182'A/jRt]53024016027O170 Attributes: Reply-Message = Request Denied Client 10.2.120.150 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client AuthBy SYSTEM Identifier SystemAuthentication /AuthBy AuthBy FILE Identifier GroupAuthentication Filename %D/users /AuthBy AuthBy INTERNAL Identifier RejectAuthAcceptAcct AuthResult REJECT AcctResult ACCEPT /AuthBy Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User AuthByPolicy ContinueWhileAccept AuthBy GroupAuthentication AuthBy SystemAuthentication /Handler Handler AuthBy RejectAuthAcceptAcct /Handler ServerHTTP Port 8100 DefaultPrivilegeLevel 15 /ServerHTTP Robb Pfrank Office +1 (312) 601-8647 r...@headlandstech.com -Original Message- From: Hugh Irvine [mailto:h...@open.com.au] Sent: Tuesday, April 03, 2012 7:24 PM To: Robb Pfrank Cc: radiator@open.com.au Subject: Re: [RADIATOR] evaluation - Checkby syntax Hello Robb - You would do something like the following: SIMPLE.CFG Foreground LogStdout LogDir . DbDir . # User a lower trace level in production systems: Trace 4 AuthPort1645,1812 AcctPort1646,1813 # You will probably want to add other Clients to suit your site, # one for each NAS you want to work with Client 1.1.1.1 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client Client 2.2.2.2 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client Client 3.3.3.3 Identifier NetworkEquipment Secret mysecret DupInterval 0 /Client .. AuthBy SYSTEM Identifier SystemAuthentication /AuthBy AuthBy FILE Identifier GroupAuthentication Filename %D/users.group /AuthBy AuthBy INTERNAL Identifier RejectAuthAcceptAcct AuthResult REJECT AcctResult ACCEPT /AuthBy Handler Client-Identifier = NetworkEquipment, Service-Type = Login-User AuthByPolicy ContnueWhileAccept AuthBy GroupAuthentication AuthBy SystemAuthentication /Handler Handler
