Re: [RADIATOR] Accounting by SQL and Authentication by ADSI
On 07/08/2010 02:18 PM, adrian wrote: > I want to authenticate my users using ADSI and Record all the acounting > Data in an SQL server. The authentication work well but i can not > record the accounting data. Below are a portion of my radius.cfg. > > > > BindStringLDAP://cn=%0,cn=Users,dc=mizona,dc=iasprueba,dc=com > > > > You may want to check the ordering of your handlers. The order should be something like this: Since Radiator matches handlers with requests by the order they appear in the configuration file, you must have more specifics first. In this example you should have Handler for accounting requests first and below that the handler that takes care of authentication. If this was not the problem, try sending more complete radius.cfg to the list for further problem spotting. > > # Adjust DBSource, DBUsername, DBAuth to suit your DB > DBSourcedbi:ODBC:Datalnet > DBUsernameradiatorlog > DBAuth radiatorlog > >AccountingTable ACCOUNTING >AcctColumnDef USERNAME,User-Name >AcctColumnDef TIME_STAMP,Timestamp,integer >AcctColumnDef ACCTSTATUSTYPE,Acct-Status-Type,integer >AcctColumnDef ACCTDELAYTIME,Acct-Delay-Time,integer >AcctColumnDef ACCTINPUTOCTETS,Acct-Input-Octets,integer >AcctColumnDef ACCTOUTPUTOCTETS,Acct-Output-Octets,integer >AcctColumnDef ACCTSESSIONID,Acct-Session-Id >AcctColumnDef ACCTSESSIONTIME,Acct-Session-Time,integer >AcctColumnDef ACCTTERMINATECAUSE,Acct-Terminate-Cause,integer >AcctColumnDef ACCTTERMINATECAUSE,Ascend-Disconnect- Cause,integer >AcctColumnDef FRAMEDIPADDRESS,Framed-Address >AcctColumnDef NASIDENTIFIER,NAS-Identifier >AcctColumnDef NASPORT,NAS-Port,integer > > > > > thanks > Adrian > > > > _______ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Trace level online changing
On 08/06/2010 02:12 PM, Arthur Konovalov wrote:
> Does proxy will work with DIAMETER protocol too?
Server farming was mentioned in this thread, so I thought I would say
something about Diameter and farming. From experience I can tell that
Diameter works with server farm. Since Diameter runs over TCP, incoming
TCP connection from a peer is accepted by one child and this child will
then handle all Diameter messages that arrive over this connection.
In other words server farm works with Diameter but it does not
distribute the messages like RADIUS over UDP.
> br,
> Arthur
>
>
>> The frontend simply proxies the requests with an "AuthBy *BALANCE" to the
>> backends where the processing occurs.
>>
>> You would set up multiple backends on different port numbers such that all
>> of your processors are working in a similar fashion.
>>
>>
>>
>>> OK,
>>> it's clear now. Thank You.
>>>
>>>
>>>> The parent process does not handle any RADIUS requests itself, so although
>>>> you have increased the debug level for the parent process, the children
>>>> are still running at Trace 3.
>>>>
>>>>
>>>>
>>> BTW, about Farming. It's unclear for me from CPU load aspect. My
>>> Radiator has big load (with 80% of peak hour), but only a few of CPUs
>>> loaded and one instance of radiusd has big load:
>>>
>>> top - 12:36:56 up 94 days, 12:59, 1 user, load average: 0.42, 0.41, 0.42
>>> Tasks: 184 total, 2 running, 182 sleeping, 0 stopped, 0 zombie
>>> Cpu0 : 0.3%us, 0.0%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si,
>>> 0.0%st
>>> Cpu1 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si,
>>> 0.0%st
>>> Cpu2 : 1.3%us, 0.0%sy, 0.0%ni, 98.7%id, 0.0%wa, 0.0%hi, 0.0%si,
>>> 0.0%st
>>> Cpu3 : 21.9%us, 0.7%sy, 0.0%ni, 76.5%id, 0.0%wa, 1.0%hi, 0.0%si,
>>> 0.0%st
>>> Cpu4 : 15.0%us, 0.3%sy, 0.0%ni, 84.7%id, 0.0%wa, 0.0%hi, 0.0%si,
>>> 0.0%st
>>> Cpu5 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si,
>>> 0.0%st
>>> Cpu6 : 0.0%us, 0.0%sy, 0.0%ni,100.0%id, 0.0%wa, 0.0%hi, 0.0%si,
>>> 0.0%st
>>> Cpu7 : 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si,
>>> 0.0%st
>>> Mem: 6096408k total, 1834452k used, 4261956k free, 212452k buffers
>>> Swap: 3998392k total,0k used, 3998392k free, 1363816k cached
>>>
>>> PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
>>> 10436 root 20 0 113m 34m 3516 R 37 0.6 373:18.71 radiusd
>>> 10435 root 20 0 113m 34m 3552 S3 0.6 13:46.54 radiusd
>>> 10437 root 20 0 87460 26m 2744 S0 0.4 0:00.02 radiusd
>>> 10438 root 20 0 87328 26m 2696 S0 0.4 0:00.03 radiusd
>>> 10434 root 20 0 72804 23m 1100 S0 0.4 0:00.09 radiusd
>>>
>>> How to achieve smooth CPUs and radiusd load?
>>>
>>>
>>> br,
>>> Arthur
>>>
>>> ___
>>> radiator mailing list
>>> radiator@open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>>>
>>
>>
>>
>> NB:
>>
>> Have you read the reference manual ("doc/ref.html")?
>> Have you searched the mailing list archive
>> (www.open.com.au/archives/radiator)?
>> Have you had a quick look on Google (www.google.com)?
>> Have you included a copy of your configuration file (no secrets),
>> together with a trace 4 debug showing what is happening?
>>
>>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
Heikki Vatiainen, Arch Red Oy
+358 44 087 6547
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ClientHook sequence?
On 08/20/2010 11:03 PM, Dave Kitabjian wrote: > Does anyone know where the "ClientHook" fits in this order-of-execution > sequence? Seems to be between steps 6 and 7. The global ClientHook runs first and right after that the client specific ClientHook is called. I also noticed that at least with version 4.7, the secret is checked after the hooks run, so the hooks can catch even those requests where the authenticator check fails. So even if the request fails with "Bad authenticator in request from ..." log message, the request would still have been available for processing with ClientHook(s). > *http://open.com.au/radiator/ref.pdf* > > * * > > *1. *Server started > > *2. **StartupHook *called > > *3. *Request received from NAS > > *4. *Global RewriteUsernames applied > > *5. **PreClientHook *called > > *6. *Client clause selected > > *7. *Client RewriteUsernames applied > > *8. *Duplicate detection done > > *9. **PreHandlerHook *called > > *10. *Handler selected > > *11.**PreProcessingHook *called > > *12. *Handler’s RewriteUsername and RewriteFunction applied > > *13. *Session database updated (accounting requests only) > > *14. *Accounting log files (AcctLogFileName and WtmpFileName) written > > *15.**PreAuthHook *called > > *16. *AuthBy clauses invoked > > *17.**PostAuthHook *called > > *18. *Statistics updated > > *19.PostProcessingHook *called (if there is a reply to be sent) > > *Integration* > > > > > > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.7 released
On 08/17/2010 07:55 AM, Stubbs, Colin wrote: > Can you guys please not release LZMA compressed RPM's yet ? Seconded. > Support for it isn't in RHEL/CentOS 5 or earlier, and while it's in > Fedora stable now it doesn't look like it'll make it into RHEL/CentOS > until version 6 is released. I mentioned to one of our customers about 4.7 being available, and they also had problems with RHEL5: % rpm -i --test Radiator-4.7-1.noarch.rpm error: Failed dependencies: rpmlib(PayloadIsLzma) <= 4.4.2-1 is needed by Radiator-4.7-1.noarch They want to use RPM so a RPM in new format would be useful for them too. -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.7 released
On 08/24/2010 11:07 AM, Heikki Vatiainen wrote: > % rpm -i --test Radiator-4.7-1.noarch.rpm > error: Failed dependencies: > rpmlib(PayloadIsLzma) <= 4.4.2-1 is needed by Radiator-4.7-1.noarch Is there any news about non-LZMA RPM packages? The above problem keeps some of RHEL5 users we know from upgrading to 4.7. An old style RPM would be highly appreciated. -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Upgrade to 4.6 caused me problems
On 09/17/2010 05:43 PM, Jethro R Binks wrote: > With reference to the problem I observed when upgrading to 4.6, where > special character %N (ref: "The NAS-IP-Address in the current request (if > any)") is printed "raw" > >> Mon Apr 26 00:03:26 2010 OK client=tambala.net.strath.ac.uk >> clientip=130.159.17.137 clientident=SquidProxy nasip=<82><9F>^Q<89> > nasid= >> naspttype= requser=abc replyuser= outeruser=abc eapidentity=, >> calling-st-id= called-st-id= fr amed-ip-addr= handler=strathrealm >> rmessage= > ... >> So note "nasip=<82><9F>^Q<89>". This is actually my terminal's >> representation of the hi-bit characters, and it turns out they are the > hex >> equivalent of the IP address: 0x82h == 130, 0x9f == 159, etc. Before > 4.6 >> (3.17.1 previously) this was seamlessly translated to a printable IP >> address, but it now appears this is being printed "raw". The messages from Apr 26, are they from a hook? If I remember correctly there have been changes to packet processing that affected the moment of decoding and translation of packet contents. So if the messages are for example, from a PreClientHook the following note from the manual may apply. 5.4.27 PreClientHook ... Caution: At the time this hook is run, integer attributes have not yet been unpacked and decoded, and encrypted attributes have not yet been decrypted. If you need unpacked, decrypted versions of these attributes, consider using a per-client ClientHook instead. ... -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.7 released
On 09/15/2010 07:49 PM, Hugh Irvine wrote: > New RPM now available on the web site. I just received a report that indicates there is at least one hard coded path that has Perl version in it. This was with the RPM packaged on 15.9. In short: Perl 5.8.8 is installed on RHEL 5.5 but somehow the RPM creates paths for 5.10.0 when installed. Can you check if the RPM could be redone once more? Thanks! Here is a transcript: # rpm -Uvh Radiator-4.7-2.noarch.rpm [ No complaints there, installation was successful] # service radiator stop # service radiator start Starting Radiator: Can't locate Radius/ServerConfig.pm in @INC (@INC contains: . /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .) at /usr/bin/radiusd line 25. [ updatedb has not yet run. Use locate to see where the old version was ] # locate Radius/ServerConfig.pm /usr/lib/perl5/site_perl/5.8.8/Radius/ServerConfig.pm [ Now check the loaction of new version] # updatedb # locate Radius/ServerConfig.pm /usr/lib/perl5/site_perl/5.10.0/Radius/ServerConfig.pm [ 5.10.0 above seems to be the problem] # perl --version This is perl, v5.8.8 built for x86_64-linux-thread-multi [ Downgrade back to working version ] # yum --nogpgcheck downgrade Radiator-4.6-1.noarch.rpm -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator Version 4.7 released
On 09/22/2010 01:37 PM, JHONNY FREIRE DE OLIVEIRA wrote: > This is what happens if try to update with the new package: > > # rpm -Uvh /root/Radiator-4.7-3.noarch.rpm > Preparing...### [100%] >1:Radiator ### [100%] > error: unpacking of archive failed on file /usr/lib/perl5/Radius: cpio: > rename failed - Is a directory > # I'll add also a bit more information. My tester reported back results from testing with a RHEL 5.5 workstation that did not have a previous installation of Radiator. Installation and upgrade was successful with: - upgrading 4.6.1 -> 4.7.3 - upgrading 4.6.1 -> 4.7.2 -> 4.7.3 Note that this was not the same server that had problems with upgrade previously, but a RHEL 5.5 workstation for testing that did not have Radiator. Results from the real server will be available later, if needed. If I remember correctly, there have been changes with RPM packaging, so could the e.g., the cpio errors result from leftovers with earlier versions? -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Issues with AuthbyNTLM (LONG)
NAS-IP-Address = 10.2.96.19
> NAS-Identifier = "Dover Standalone (Thick) AP"
> NAS-Port = 16973824
> Calling-Station-Id = "00-13-ce-69-43-2c"
> User-Name = "anonymous"
>
> Wed Sep 22 12:05:59 2010: DEBUG: Handling request with Handler '', Identifier
> ''
> Wed Sep 22 12:05:59 2010: DEBUG: Deleting session for anonymous, 10.2.96.19,
> 16973824
> Wed Sep 22 12:05:59 2010: DEBUG: Handling with Radius::AuthNTLM:
> Wed Sep 22 12:05:59 2010: DEBUG: Handling with EAP: code 2, 8, 67, 26
> Wed Sep 22 12:05:59 2010: DEBUG: Response type 26
> Wed Sep 22 12:05:59 2010: DEBUG: Radius::AuthNTLM looks for match with
> CAMC\tssmith [anonymous]
> Wed Sep 22 12:05:59 2010: DEBUG: Radius::AuthNTLM ACCEPT: : CAMC\tssmith
> [anonymous]
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute Request-User-Session-Key:
> Yes
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute
> Request-LanMan-Session-Key: Yes
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute LANMAN-Challenge:
> 179b1eda2032ef41
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute NT-Response:
> daeba61f0a85e54146443ce2dd87bd62e571a30bf82d2204
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute NT-Domain:: Q0FNQw==
> Wed Sep 22 12:05:59 2010: DEBUG: Passing attribute Username:: dHNzbWl0aA==
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: Authenticated: Yes
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: LANMAN-Session-Key:
> 55FC5F8DFAA3A58D
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: User-Session-Key:
> B48DFF252D4FAB7CBEA3207E1A5C51BE
Everything looks good so far. ntlm_auth gets a success back from the
Windows server and also the User-Session-Key it requested.
If I have understood correctly the User-Session-Key should be a MD4 hash
of NTHash the the Windows server stores. In other words
md4(md4(asciitounicde(password))) which with plain 7bit ascii is simply
md4(md4(password))
The broken ntlm_auth does not return this double hash of password, but
instead of some other value. This value causes incorrect "authenticator
response" to be calculated and makes the client think that the server
does not know the real password hash. In other words the server
authentication to the client fails.
What happens is that client ends the authentication and no reply is ever
received until a new try is initiated by the client. Just like below,
the last message is the message to the client.
Looking at Radiator goodies directory, the simplest method to generated
User-Session-Key from a known password is this:
% perl goodies/nthash.pl password
{nthash}8846F7EAEE8FB117AD06BDD830B7586C
% perl goodies/nthash.pl 8846F7EAEE8FB117AD06BDD830B7586C
{nthash}0204D0612AF59BDABC236E5195648836
The hex string 0204D0612AF59BDABC236E5195648836 is the User-Session-Key
for the password 'password'.
> Wed Sep 22 12:05:59 2010: DEBUG: Received attribute: .
> Wed Sep 22 12:05:59 2010: DEBUG: EAP result: 3, EAP MSCHAP V2 Challenge:
> Success
> Wed Sep 22 12:05:59 2010: DEBUG: AuthBy NTLM result: CHALLENGE, EAP MSCHAP V2
> Challenge: Success
> Wed Sep 22 12:05:59 2010: DEBUG: Access challenged for anonymous: EAP MSCHAP
> V2 Challenge: Success
> Wed Sep 22 12:05:59 2010: DEBUG: Returned PEAP tunnelled packet dump:
> Code: Access-Challenge
> Identifier: UNDEF
> Authentic: <232><180><135>ho<23><1><169><169><10><215>4<199><184><149>I
> Attributes:
> EAP-Message =
> <1><9><0>=<26><3><8><0>8S=AD59BE8E0A96165332AEEBF926A4002E20868CDB M=success
> Message-Authenticator =
> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>
> Wed Sep 22 12:05:59 2010: DEBUG: EAP result: 3, EAP PEAP inner authentication
> redispatched to a Handler
> Wed Sep 22 12:05:59 2010: DEBUG: AuthBy NTLM result: CHALLENGE, EAP PEAP
> inner authentication redispatched to a Handler
> Wed Sep 22 12:05:59 2010: DEBUG: Access challenged for CAMC\tssmith: EAP PEAP
> inner authentication redispatched to a Handler
> Wed Sep 22 12:05:59 2010: DEBUG: Packet dump:
> *** Sending to 10.2.96.19 port
> Code: Access-Challenge
> Identifier: 45
> Authentic: <155><216><173><221>2<245><196><238><211>w\<24><174>m<245>3
> Attributes:
> EAP-Message =
> <1><9><0>T<25><0><23><3><1><0>I<10><160><227><173><198>N<190>HO<14><186><171><197><251>Z<154><195>g<232><147><254>#<238><129>7x^6'S\<134>A`qL<203><253><14><28>p<190><232>%M<224>w<148><215><176><170>UW<22><193><168>6<147><25><249><255><7><3><137><22><192><193><190>M<202><236><153>[
> Message-Authenticator =
> <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>
> ^C
--
Heikki Vatiainen, Arch Red Oy
+358 44 087 6547
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerHTTP
On 10/13/2010 10:48 PM, Smith, Todd wrote: >>> If there is a limit to the logfile size, can you limit the size >>> of a logfile being created? > >> There are no features for rotating/changing log files based on >> size. > > This would seem to be a nice feature request since some other RADIUS > servers can do this and some customers might have functionity based > around size. It is not a show-stopper for me since as long as I can > read the file then it is good enough. One thing which might help with size based rotating is mentioned in section 5.11 in the reference manual. The file can be rotated any time since it is not kept open but only opened when needed. For example logrotate, which comes with many Linux distributions, can rotate logs based on their size. This approach lets the logrotating software take care of (delay)compressing, renaming, moving to holding directories and doing other log specific house keeping. -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] LDAP authentication, IBM Lotus Domino
On 11/08/2010 01:46 PM, Martin Burton wrote:
> Hi Pekka,
>
> We normally do something along the lines of:
I'll add one more thing. We have successfully used HoldServerConnection
flag with AuthBy LDAP2, so Pekka, you may want to see if it works with
your LDAP server too. Please see section 5.36.17 in Radiator 4.7
reference manual for more.
In short, this keeps the TCP connection to LDAP server open, but not all
LDAP server work correctly if the same connection is used for multiple
searches. If it works, it should be good for performance. If it seems
not to work, just remove HoldServerConnection from the configuration.
We used it with Novell's eDirectory and LDAPS (SSL) connection with good
results. The manual has no mention for IBM, so this might be interesting
once initial evaluation has been done and further tuning is done.
> # Split the LDAP auth into its own clause since it's used in
> # many different realms
>
> Identifier SangerLDAP
> Host xx.sanger.ac.uk
> BaseDN ou=x,dc=sanger,dc=ac,dc=uk
> UsernameAttr uid
> PasswordAttr userPassword
> # Ask the LDAP server to attempt to bind as the user,
> # saves having to maintain auth credentials within this
> # config file.
> ServerChecksPassword
>
>
> # Handle logins to cisco switches.
> # The switch details are held in the RADCLIENTLIST
> # MYSQL table with a default realm set in there.
>
> # Strip realm from username
> RewriteUsername s/^([...@]+).*/$1/
> AuthBy SangerLDAP
>
>
> ...
>
>
> ...
> AuthBy SangerLDAP
> ...
>
>
> ...
>
> Hope that helps.
>
> Regards,
>
> Martin.
>
>
> On 08/11/10 10:53, pekka.pan...@sofor.fi wrote:
>> Hi
>>
>> I am new to Radiator and we currently evaluating it. I am trying to use
>> LDAP2 auth from IBM Lotus Domino LDAP-server (without success yet).
>>
>> I am wondering how can i strip realm from username or how to set username,
>> i have a working freeradius conf here:
>>
>> ldap {
>> server = "1.2.3.4"
>> port = "399"
>> basedn = "o=Sparknet"
>> filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
>> base_filter = "(objectclass=person)"
>> ...
>> }
>>
>> How is that converted to Radiator?
>>
>> Terveisin/Regards,
>>Pekka Panula, Sofor Oy - Jatkuvat palvelut
>>
>>
>>
>>
>> ___
>> radiator mailing list
>> radiator@open.com.au
>> http://www.open.com.au/mailman/listinfo/radiator
>
>
>
> ___
> radiator mailing list
> radiator@open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
Heikki Vatiainen, Arch Red Oy
+358 44 087 6547
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Backing up Radiator
On 11/30/2010 01:18 PM, Ricardo Freitas wrote: > I would like to know what is the best way to backup all my system > configuration and radiator files. There are a couple of possibilities to do this. The best method depends mostly on your configuration and how you have installed Radiator. I would start by backing up the configuration directory, normally under /etc, the logging directory and other locations that are best checked from the Radiator configuration file. If you have installed Radiator from .tar.gz file and have not done make install, you can roll it back to a .tar.gz archive. If you have done make install, then Radiator files have been copied into directories such as /usr/lib/perl5/site_perl/. If you do "make -n install" as non-root user, you can check what the installer would do and where the files are copied to. You should be careful to check the locations especially if you have modified the Radiator files yourself. In this case you want to make sure that all these modifications are part of the backup. When you have collected the Radiator files get a list of installed packets and programs on your server. On Linux something like "dpkg -l" or "rpm -qa" should give you the view what packages, and especially Perl packages you have installed. If you run Windows, check the Windows installation instructions mentioned below. Please check http://www.open.com.au/radiator/documentation.html and the installation instructions. These instructions will help you to locate the important packages that Radiator needs. For example, if you need MS-CHAP or MS-CHAPv2, you must have the MD4 digest package. Otherwise you will get problems during the runtime. > Any of you guys have made this in the past? It is possible, but depends a lot how you have done the installation and what your configuration is. > I'm guessing this is a bit more tricky than just copying the files from > the server to a backup up computer. It can be as easy as that, especially if you can easily duplicate your server installation. Of course then there is the question of firewall rules, database access lists and so on, but then again, it depends on what your needs are. In other words, collecting the Radiator distribution and configuration files should be quite straight forward and creating a backup server involves much more work. > Thank you for the help My pleasure. I'll try to summarize a bit: If are running from the distribution directory, copy it to the backup. If you have done make install, copy the distribution directory you did make install from and see the perl site-perl directories. In both cases, remember the configuration directory, log directory and check the configuration file for other locations and files such as certificates. Also make sure that local modifications, if any, get backed up. I strongly recommend setting up a test server for testing the backup and backed up configuration. > Ricardo Heikki -- Heikki Vatiainen 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] Updated Radiator - error Can't locate object method "readConfig"
On 12/08/2010 07:18 PM, Ricardo Freitas wrote: > Just upgraded Radioator to the latest version and have Perl 5.8.8 also > running. > > When trying to run "radiusd --config_file > /my_radius_config_file_instance" I get the following error: > > > "Can't locate object method "readConfig" via package > "Radius::ServerConfig" at /usr/bin/radiusd", on ilne 181 > > > Could this be an error due too some obsolete configuration on the config > file? I fear it could be a Radiator error, since the file radiusd is the > one reporting the error. Christian already mentioned that radiusd needs to match the Radiator perl modules and for me it looks like your radiusd is picking up the modules from the old version. Try the following to test the new version (all on one line): perl -I /path_to_latest_version radiusd --config_file /my_radius_config_file_instance In other words, -I prepends the new version to the module search path making it possible for perl to pickup the new version modules. The /path_to_latest_version should be the path that contains Radius/ subdirectory from the Radiator distribution. This is the directory that is created when you uncompress the distribution package. > I had the radiator version 2.1.9 (yeah, really old..) > > Thanks guys, appreciate any help you can provide. Please let us know if this helps. -- Heikki Vatiainen 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] Ignore Accounting packets from certain hosts
On 12/10/2010 08:37 AM, Michael wrote: > Yes, but i wouldn't recommend it. If your NAS is ignored, it may mark > your radius server as RADIUS_DEAD, if cisco. Depends on your NAS i guess. > > If you just don't want to do anything with the accounting, it's probably > better to just ACCEPT and do nothing with it, but if you truley want to > ignore, you can. If ignored, your NAS would probably move to the next > radius server in its config and try the accounting on that radius server. > again, depends on NAS config. Good points. I'll just add one more thing: the handler must be before any other handlers that might match the request. The order of handlers matters when matching incoming requests. > ...for Accounting only: >Request-Type = Accounting-Request, \ > User-Name = /@xyz.com$/, \ > NAS-IP-Address = 1.1.1.1|1.1.1.2|1.1.1.3> > > >DefaultResult IGNORE <- use this to ignore >DefaultResult ACCEPT <- use this to accpet > > > > > > But, if you want to use the realm option, and have authentication to: > > > ... > > > ... > > > # this will reply ACCEPT to the NAS, > # but do nothing with it. > AccountingHandled > > > > > Michael > > > > > On Fri, 10 Dec 2010, Zaeem Arshad wrote: > >> Hi List, >> >> We are testing a scenario where we require our radiator radius server >> to ignore accounting packets from certain NAS hosts if the user >> belongs to realm xyz.com. Is that possible? >> >> >> Regards >> >> Zaeem >> ___ >> radiator mailing list >> radiator@open.com.au >> http://www.open.com.au/mailman/listinfo/radiator >> > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] Seeking clarification on AuthBy LDAP2 PostSearchHpok
On 12/17/2010 11:06 PM, Andrew Clark wrote: > I've just got a simple question about a PostSearchHook when an AuthBy > LDAP2 experiences a server timeout. I know that AuthBy will return an > IGNORE, but is the PostSearchHook skipped or does it still execute? It does not execute. When the search terminates due to a timeout, you should see something like this in the log: ERR, "ldap search for $filter failed with error LDAP Timeout. ERR, "Disconnecting from LDAP server (server $server:$port) After the disconnect ERR, the search returns and the hook is not run. In other words: the hook is only run if the results were received without an error. MaxRecords controls how many results are examined, if there are multiple results, and the hook runs for each result. Does this sound like what you were expecting? Thanks! -- Heikki Vatiainen 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] AuthBy LDAP2 failover with round-robin DNS?
On 12/17/2010 11:29 PM, Christian Kratzer wrote: >> one more quick question. What is the behavior of AuthBy LDAP2 with a >> round-robin DNS entry (multiple A records for the RR)? If I'd like >> failover behavior, will a single Host declaration with a round-robin >> record be enough, or do I need to list out each individual LDAP >> server? > > you should explicitly list all servers as Dns will get resolved once > on load of config. That is true with e.g. Clients, but from the manual it looks like AuthBy LDAP2 behaves a bit differently. Quote: Multiple space separated host names can be specified and Net::LDAP will choose the first available one. A quick check shows that the host name(s) are passed to Net::LDAP which takes care of resolving names to addresses. Note also how the doc below says hosts are tried until there is success. http://search.cpan.org/~gbarr/perl-ldap-0.4001/lib/Net/LDAP.pod#new Radiator seems to create a new Net::LDAP for each (re)connect so it might be that DNS is queried when there was a disconnect and a reconnect needs to be done. So listing the hosts, like Christian writes, seems to be easier than trying to follow Net::LDAP's method of resolution. -- Heikki Vatiainen 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] Dynamically assign VLAN to wireless clients
On 12/20/2010 05:25 PM, Patrick Renkens wrote: > PostAuthHook to replace the default Tunnel-Private-Group-ID in the > reply-packet with the generated ID now runs OK. > > I placed the PostAuthHook after the AuthBy clause in the handler for the > outer tunnel. A first glance learns that it works. > But we assume that a re-authentication - for whatever reason - will > possible place the wireless client in a different VLAN. > Is there a way to preserve this behaviour, or to keep the session intact > with a re-authentication? If I understood correctly, you have the same requirement that was discussed on this list previously: http://www.open.com.au/pipermail/radiator/2010-November/016769.html Please check the thread and see if EAPTLS_SessionResumption 0 does the trick for you. Thanks! > Kind regards, > Patrick Renkens > Centre for Information Services (UCI) > Radboud University Nijmegen, Netherlands > > > > > Op 12-11-2010 17:31, Patrick Renkens schreef: >> >> Hi All, >> >> We would like to dynamically assign VLAN's to wireless clients. >> All of the authentication process (inner and outer tunnel etc.) runs OK, >> but the last step should be assigning a dynamic VLAN ID >> (Tunnel-Private-Group-ID) to the client in a short range of ID's. >> >> Can this be done, and if so, how? >> >> I already wrote a small PostAuthHook that can generate a random VLAN-ID >> within this short range of ID's. It replaces the default >> Tunnel-Private-Group-ID in the reply-packet with the generated ID, but >> it doesn't do the trick. It does replace the Tunnel-Private-Group-ID but >> is has no affect on the process (so it seems). >> >> The reason for this feature is that the current VLAN is too small and we >> prefer to have several VLAN's for the wireless clients instead of a much >> larger single VLAN. >> >> Any other ideas or workarounds are also appreciated. >> >> Kind regards, >> Patrick Renkens >> Centre for Information Services (UCI) >> Radboud University Nijmegen, Netherlands >> >> >> ___ >> radiator mailing list >> radiator@open.com.au >> http://www.open.com.au/mailman/listinfo/radiator >> > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] radpwtst - sending multiple packets
On 01/05/2011 03:07 PM, Michael wrote: > I'm trying to figure out the best way to send multiple radius packets to > a server. It seems that executing radpwtst once for each individual > packet is pretty slow. I assume it is slow since it has to compile, > parse the dictionary, and do whatever else radpwtst has to do each time > it is run. I'm wondering if there is a way to have radpwtst run once, > and send/receive multiple packets. Björn already had some comments, so I thought I'd check that you have noticed the -iterations parameter? With -iterations, the sequence number changes, so the requests are not complete duplicates. > I see there is a -rawfileseq option that appears to do this, but i don't > see this as being a documented option in the manual. How do you > generate raw packets to build a raw file? Try the following: cat eaptest1.dat > packets.raw echo "NewPacket" >> packets.raw cat eaptest2.dat >> packets.raw In other words, the eaptest*.dat files are already raw files. String "NewPacket" is the marker between individual messages in the file. The resulting packets.raw is probably not useful for testing, but when you run Radiator with trace 4, you can see what the attributes contained in the raw file are and verify that your raw file is good. Each seq(uence) contains all of Code, Identifier, Length, Authenticator and Attributes. It is a complete RADIUS packet in hex format. -- Heikki Vatiainen 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] Help required with EAP TTLS
On 01/07/2011 01:51 PM, Aman Arneja wrote: > I also need some information regarding your ttls support since i am looking > at a radius server that can service both SIM and TTLS requests, i need the > answers to the following questions. Good questions. Please see below for answers. > Features > Non-EAP inner methods - Which methods are supported? There are plenty: the basic ones are PAP, CHAP, MSCHAP ja MSCHAPv2. The way Radiator has been built makes supporting different inner methods easy. The inner method messages are dispatched as new RADIUS messages and can be handled in the configuration as their own, not within TTLS. In other words there is a lot of flexibility with the inner protocols, and the ones mentioned above are usually supported and used by clients. Do you have any specific methods in mind? > Client auth during phase 1 - Supported, Not/Supported Supported. The phase 1 message is available for authentication. You can for example, first validate MAC address or check WLAN SSID in the outer request and only then proceed to continue with phase 2. > Can identity privacy be explicitly enabled or disabled - on the client side > Can session resumption be explicitly enabled or disable - on the client side Yes for both. The outer identity can be different from the inner identity. Session resumption is supported by Radiator by default and can be disabled from the client side. > Method chaining in Phase 2 For this you would need to use Radiator with e.g., EAP-FAST where method chaining has been well defined. With TTLS methods can in theory be chained with clever configuration, but I do not think Radiator has been tested or used in such a configuration. If you have something specific in mind, please let us know. > Allowing tunnel method as inner method (FAST, PEAP) This may not been ever tested and I can not verify if this works. If you know a client that can do this, we would be very interested to know about it. > Also if you have any competitor analysis on this , like with free radius > etc, that would be great !! Please take a look Radiator technical information at http://www.open.com.au/radiator/technical.html I will check what analysis type of information we may also have. > Thanx > > Aman Arneja Thanks! Heikki Vatiainen -- Heikki Vatiainen 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] TTLS and AuthbyLSA
On 01/10/2011 05:02 PM, Johnson, Neil M wrote:
> I'm using eapol_test from the wpa_supplicant sources.
Can you try MSCHAPv2 instead of EAP-MSCHAPv2? If plain MSCHAPv2 runs in
the TLS tunnel, then the User-Name attribute should be there too.
Is there a specific reason why you are running EAP-MSCHAPv2?
> My config file is:
> #
> # eapol_test -c ttls-eap-mschapv2.conf -a server -s secret
> #
> network={
> ssid="example"
> key_mgmt=WPA-EAP
> eap=TTLS
> identity="nmjoo"
> anonymous_identity="nmjoo"
> password="secret"
> phase2="autheap=MSCHAPv2"
phase2="auth=MSCHAPV2"
> #
> # Uncomment the following to perform server certificate validation.
> # ca_cert = /etc/raddb/certs/ca.der
--
Heikki Vatiainen
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] Help with EAP-SIM simulator for evaluation
On 01/10/2011 05:34 PM, Effi Rand wrote: > I need some help with the configuration of the radiator as a MAP-GATEWAY with > radius interface. I'm not that experienced in this product and it's important > for me to evaluate this feature since the expire date is due in 2 weeks. > > I was able to test the EAP-SIM with the SSGN simulator using the "odyssey" > wireless client (after we cached some triplets to a local file) > However , when I try to test it with the MAP-GATEWAY simulator (same client), > I fail to get the access-accept message. There are a couple of things you should try. I will go through them below: > # radius.cfg > # $Id: linux-radius.cfg,v 1.3 2002/03/24 23:07:49 mikem Exp $ Looks like most of the content is from goodies/eap_simoperator.cfg > AuthPort 1645,1812,1647 > AcctPort 1646,1813,1648 Please remove ports 1647 and 1648 since they will be used by map.cfg > > > # The name or address of the example MAP gateway(s) that will > server this instance > # Radius requests are sent to this gateway requesting > triplets etc. > Host localhost > AuthPort 1647 > Secret cisco Please check README section "Testing with the Radius MAP gateway simulator". What you should have listening on localhost port 1647 is another Radiator running configuration from goodies/map.cfg The example mpa.cfg uses port 1647 with secret mysecret What happens now is that this Radiator instanc gets the request that is intented for the MAP simulator. Like README says, you should two Radiator instances running at the same time: 4. Run the MAP gateway simulator: radiusd -config goodies/map.cfg 5. Run Radiator EAP-SIM server radiusd -config goodies/eap_simoperator.cfg > > TripletsFile /tmp/Modules/Radius-EAP-SIM/goodies/triplets.dat > Pin > Remove the block. This AuthBy will be handled by the second Radiator that uses map.cfg > > Another thing , in the README file , you mention that there is also a > cisco-ipt simulator under Radius-EAP-SIM/goodies/ciscomap.cfg > > There is no file like that. You are correct. If will check what has happened to it. > Another question , so far I've failed to test the iPhone EAP-SIM client > against the EAP-SIM simulator. Any idea what can be done ? I have not tried iPhone myself, but unless you have already downloaded iPhone configuration utility from Apple you may want to do that. The utility gives you control over many things, including WLAN settings where you can disable all the other WPA-Enterprise methods. Thanks! -- Heikki Vatiainen 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] TTLS and AuthbyLSA
On 01/10/2011 05:48 PM, Johnson, Neil M wrote: > TTLS-MSCHAPv2 works. Great! > I was confused. I thought ttls-eap-mscahpv2 was ttls-mschapv2. Well, I did not notice this either until I checked wpa_supplicant doc and took a peek at the code. Only then I realised that EAP is not necessary and plain MSCHAPv2 over TTLS tunnel works too and that is the common case. > Still, it be nice to know why the inner identity is being found. I think what I wrote about checking both EAP Identity and User-Name attribute might be useful if someone, for some reason, wants to use EAP-Someting over TTLS tunnel. But I guess it is quite infrequent. TTLS RFC states that CHAP, MSCHAP and MSCHAPv2 must include User-Name but there is no such requirement for EAP. -- Heikki Vatiainen 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] Can't get chain certificates to work
On 01/11/2011 03:35 AM, Rianto Wahyudi wrote: Hello Rianto, > Im having some difficulties getting the certificate to work correctly. > I followed instructions from > http://www.open.com.au/pipermail/radiator/2010-November/016781.html, > > Windows Clients still get prompted with a warning message saying that the > certificate can not be trusted : > The server "eduroam.latrobe.edu.au" presented a valid certificate > issued by "thawte Primary Root CA", but "thawte Primary Root CA" is not > configured as a valid trust anchor for this profile. Please send your certificate file (eduroam.crt) or at least the Subject and Issuer information from it. Looks like there is either a problem with the certificate chain, missing or incorrect CA certs, or you have selected incorrect root certificate in your Windows Client configuration. Also tell us how you have configured your Windows Client and what you have selected as a root CA (trust anchor). > Following are my config file : > > EAPTLS_CAFile /etc/radiator/certs/thawte-ssl-ca-bundle.pem > EAPTLS_CertificateChainFile /etc/radiator/certs/eduroam-combined > EAPTLS_CertificateType PEM > EAPTLS_PrivateKeyFile /etc/radiator/certs/eduroam.latrobe.edu.au-rsa.key This looks good. With the above setup, the most important file is EAPTLS_CertificateChainFile. The order of file contents is important: the first certificate must be the server certificate followed by the CA certs. The CA certs can be in any order, but what is important is that the servert cert is the first. The cat command you have used does this correctly. The EAPTLS_CAFile must always be specified, but its contents seem not to be important. It needs to contain a valid CA cert though. This file matters more if certs are configured without EAPTLS_CertificateChainFile > thawte-ssl-ca-bundle.pem contains file from : > https://search.thawte.com/library/VERISIGN/ALL_OTHER/thawte%20ca/SSL_CA_Bundle.pem This bundle seems to have the following two certificates: Cert 1: -- Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailaddress=premium-ser...@thawte.com Subject: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Cert 2: --- Issuer: C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA Subject: C=US, O=Thawte, Inc., CN=Thawte SSL CA > eduroam-combined contain : > cat eduroam.crt thawte-ssl-ca-bundle.pem > eduroam-combined > > > Running eapol_test return following error : > TLS: Certificate verification failed, error 20 (unable to get local issuer > certificate) depth 2 for '/C=US/O=thawte, Inc./OU=Certification Services > Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary > Root CA' > CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=2 subject='/C=US/O=thawte, > Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For > authorized use only/CN=thawte Primary Root CA' err='unable to get local > issuer certificate' > SSL: (where=0x4008 ret=0x230) > SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA > SSL: (where=0x1002 ret=0x) > SSL: SSL_connect:error in SSLv3 read server certificate B > OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL > routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed > SSL: 7 bytes pending from ssl_out > SSL: Failed - tls_out available to report error > SSL: 7 bytes left to be sent out (of total 7 bytes) > EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL Best regards, Heikki -- Heikki Vatiainen 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] Radiator Pro Pack License Details
On 01/11/2011 01:48 PM, Aman Arneja wrote: > The radiator Pro Pack ( 7 server licenses ) is it limited to 1 year use ? or > 1 year support? I am sending a copy to i...@open.com.au for an authoritative answer to your question. My non-authoritative answer comes from the Order web page: "All Licenses are perpetual and include the first year access to new releases and patches." So the license itself is not limited. Support for one year is included with the initial licensing. After that it can be renewed for additional years. It is also possible to order support and access to new releases and patches for additional years with the initial licensing. > The wording is a little deceptive. I hope I was able to clarify this. Lets also see what i...@open.com.au has to add. Best regards, Heikki Vatiainen -- Heikki Vatiainen 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] Can't get chain certificates to work
On 01/11/2011 01:58 PM, Rianto Wahyudi wrote: Hello, > I did not choose or select any trusted root certification authorities / > anchor as I originally tought that windows is smart enough to do it > automatically. It probably could choose it automatically, but I think it will not for security reasons. In other words, this should be considered a feature. It it automatically accepts a certificate that has a known root CA and valid CA certificate chain, this leaves the client vulnerable to attackers with a valid certificate from any valid root CA. For example many eduroam sites advice the users to choose these from Windows PEAP settings: - Validate server certificate - Connect to these servers (eduroam.latrobe.edu.au in your case) - Choose the correct CA cert from the list of "Trusted Root Certificate Authorities" - Check "Do not prompt user to authorize new servers ..." When these are set, the client will only build TLS tunnel to your server. > If I select thawte Primary Root CA as trusted anchor the connection seems to > be working. Sounds correct. I also took a look at the certificate you send, and the CA path seems to be correct. Your cert was signed by "Issuer: C=US, O=Thawte, Inc., CN=Thawte SSL CA" > The other problem is that not all client have that specific thawte > certificate installed on their PC. I think that thawte certificate is very common. It should be installed in most systems. > Do you think I should change certificate provider ? If so do you guys have > any recommendation of which SSL provider I should use ? I think your certificate provider should be common enough so that changing would not be that useful. I can not name a provider that would be better. There are many I would say are equally common, but I can not name any that is considereably more common than the one you have. > In windows 7, do you have to select a trusted root certification authorities > or will it just work automatically if I use well known provider ? I do not remeber how windows 7 behaves if you have not chosen the CA. It will probably at least show the certificate and prompt it should be accepted. Please consider that choosing the CA and naming the radius server can be thought as a feature and should be done to make sure your client does not end up sending its credentials to unknown, possibly hostile, servers. It's a bit of work, but it need to be done only once per client. > Regards, > Rianto Best regards, Heikki -- Heikki Vatiainen 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] TTLS and AuthbyLSA
Jan 7 17:11:28 2011: DEBUG: AuthBy LSA result: CHALLENGE, EAP TTLS
> Challenge
> Fri Jan 7 17:11:28 2011: DEBUG: Access challenged for nmjoo: EAP TTLS
> Challenge
> Fri Jan 7 17:11:28 2011: DEBUG: PostProcessing Hook: called.
> Fri Jan 7 17:11:28 2011: DEBUG: Packet dump:
> *** Sending to 128.255.204.94 port 59392
> Code: Access-Challenge
> Identifier: 5
> Authentic: <1>Z<202>O<243>9K<205><159><230><29><246>
> Attributes:
> EAP-Message = <1><6><3><238><21>@U<4><10><19><11>AddTrust
> AB1&0$<6><3>U<4><11><19><29>AddTrust External TTP Network1"0
> <6><3>U<4><3><19><25>AddTrust External CA
> Root0<30><23><13>000530104838Z<23><13>200530104838Z0o1<11>0<9><6><3>U<4><6><19><2>SE1<20>0<18><6><3>U<4><10><19><11>AddTrust
> AB1&0$<6><3>U<4><11><19><29>AddTrust External TTP Network1"0
> <6><3>U<4><3><19><25>AddTrust External CA Root0<130><1>"0<13><6><9>*<134>
> EAP-Message =
> H<134><247><13><1><1><1><5><0><3><130><1><15><0>0<130><1><10><2><130><1><1><0><183><247><26>3<230><242><0><4>-9<224>N[<237><31><188>l<15><205><181><250>#<182><206><222><155><17>3<151><164>)L}<147><159><189>J<188><147><237><3><26><227><143><207><229>mPZ<214><151>)<148>Z<128><176>Iz<219>.<149><253><184><202><191>78-<30>><145>A<173>pV<199><240>O?<232>2<158>t<202><200><144>T<233><198>_<15>x<157><154>@<<14><172>a<170>^<20><143><158><135><161>jP<220><215><154>N<175><5><179><166>q<148><156>q<179>P`<10><199><19><157>8<7><134><2><168><233><168>i&<24><144><171>L<176>O#<171>:O<132><216><223><206><159><225>io<187><215>B<215>kD<228><199><173><238>mA_rZq<8>7<179>ye<164>Y<160><148>7<247><0>/<13><194><146>r<218><208>8r<219><20><168>E<196>]*}<183><180><214><196><238><172><205><19>D<183><201>+<221>C<0>%<250>a<185>ijX#<17><183><167>3<143>VuY
> EAP-Message =
> <245><205>)<215>F<183><10>+e<182><211>Bo<21><178><184>{<251><239><233>]S<213>4Z'<2><3><1><0><1><163><129><220>0<129><217>0<29><6><3>U<29><14><4><22><4><20><173><189><152>z4<180>&<247><250><196>&T<239><3><189><224>$<203>T<26>0<11><6><3>U<29><15><4><4><3><2><1><6>0<15><6><3>U<29><19><1><1><255><4><5>0<3><1><1><255>0<129><153><6><3>U<29>#<4><129><145>0<129><142><128><20><173><189><152>z4<180>&<247><250><196>&T<239><3><189><224>$<203>T<26><161>s<164>q0o1<11>0<9><6><3>U<4><6><19><2>SE1<20>0<18><6><3>U<4><10><19><11>AddTrust
> AB1&0$<6><3>U<4><11><19><29>AddTrust External TTP Network1"0
> <6><3>U<4><3><19><25>AddTrust External CA Root<130><1>
> EAP-Message =
> <1>0<13><6><9>*<134>H<134><247><13><1><1><5><5><0><3><130><1><1><0><176><155><224><133>%<194><214>#<226><1
Re: [RADIATOR] FW: Help with EAP-SIM simulator for evaluation
On 01/12/2011 06:01 PM, Effi Rand wrote: Hello Effi, > I have tried it with your remarks (though I had to use the > eap_simoperator.cfg as the /etc/radius.cfg , with the map.cfg as a second > instance) and it worked. Good to hear. > I still can't get the iPhone EAPSIM authentication to work even though the > MAP output says it's accepted. The log from the main instance says not enough > credentials. Please check the value of NumTriplets in your configuration file. Based on the log below, the value seems to be 2. Try with 3. The EAP SIM RFC says valid values are 2 or 3 and the correct settings depends on the peer policy. Note that if you are using triplets file, you need to extract more triplets in it in case you have only extracted two so far. > Code: Access-Request > Identifier: 8 > Authentic: 9"<236><26>SC<225><171><209><9><18><251><155><225><135><211> > Attributes: > GSM-IMSI = "310410318197284" > GSM-NumTriplets = 2 Two triplets are being requests from MAP. > Tue Jan 11 17:46:56 2011: WARNING: EAP SIM Client Error code 2: Insufficient > Challenges Two is not enough for the client. > Log from the map: The MAP log also shows two triplets being used. > Any idea on the cause ? ofcourse I used the iphone utility to set the EAPSIM > authentication. Please let us know if this gets iPhone working. Thanks! Heikki -- Heikki Vatiainen 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] FW: Help with EAP-SIM simulator for evaluation
On 01/13/2011 11:12 AM, Effi Rand wrote: > I've tried with 3 triplets option like you suggested cached more triplets, > and now it's just stuck at some challenge phase , and iPhone just says > "unable to connect" Can you send me the both configuration files and both logs when you tried with three triplets? I'd like to see what the configuration currently looks and what gets logged. The logs should have all messages starting from the initial Access-Request. Thanks! -- Heikki Vatiainen 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] Problem after adding when I use the -c option
On 01/13/2011 12:01 PM, Gerard Alcorlo Bofill wrote: > Hi Hugh, Not Hugh, but I'll try my best :) > I'm using the latest patched Radiator version 4.7. > After adding to my Radiator config file the option, I'm > getting this error. > > # /usr/local/bin/radiusd -c -config_file /etc/radiator/config.cfg > Error: > creating socket: Address already in use > at /usr/local/share/perl/5.10.1/Radius/SNMPAgent.pm line 574 > Thu Jan 13 10:21:16 2011: ERR: Could not open SNMP Agent port 1161 on > X.X.X.X: Address already in use > Thu Jan 13 10:21:16 2011: DEBUG: Finished reading configuration file > '/etc/radiator/config.cfg' Since the port is 1161, you have probably specified "Port 1161" for . The error indicates something else is already using this port. Please check that this port is not specified in any AuthPort, AcctPort or any other configuration keyword elsewhere in the configuration. Or do you already have another process using that port? > The -c option (from the reference manual): > Parse the configuration file, reporting errors in the usual way, then exit. > > In my opinion this extra check wouldn't need to be done. Do you think > I'm right? Are you going to change this behaviour? I am not aware of plans to change this behaviour. Activating the modules to see if e.g., a port can be used does reveal errors in configuration that simple parsing would not find. This does make testing a bit problematic on a production server, but gives better results if you have a dedicated server for testing. -- Heikki Vatiainen 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] FW: Help with EAP-SIM simulator for evaluation
On 01/13/2011 05:18 PM, Effi Rand wrote: > As per request , I'm attaching the outputs of config + logs. > Radiator log: Thanks! Your configuration looks correct. There is one thing in the log that looks curious. User-Name and EAP Identity are both set to "fred". This value is used by Radiator when e.g., TestClient is in use. If your client is iPhone, can you get any logs from it to tell why it does not like the three triplets it receives. Also, is it possible to reset the phone or find out where "fred" is coming from. It looks to me like something has been cached and still used even if it should not. Also you may want to regenerate the triplets, remove old and add new, so that you get a fresh testing environment. > Thu Jan 13 17:17:17 2011: DEBUG: Packet dump: > *** Received from 10.22.11.200 port 2048 > > Packet length = 121 > 01 00 00 79 b2 0d 99 a1 f0 9e 9d ff 24 de 2b a8 > fc b5 63 a6 01 06 66 72 65 64 04 06 0a 16 0b c8 > 1e 0e 30 32 31 64 37 65 34 62 30 37 35 62 1f 0e > 30 30 31 63 62 33 31 36 36 39 65 38 20 0e 30 32 > 31 64 37 65 34 62 30 37 35 62 05 06 00 00 00 17 > 0c 06 00 00 05 78 3d 06 00 00 00 13 4f 0b 02 00 > 00 09 01 66 72 65 64 50 12 ae 25 98 d0 3d c3 28 > c9 8b 5b 1d e4 66 2f 82 ea > Code: Access-Request > Identifier: 0 > Authentic: > <178><13><153><161><240><158><157><255>$<222>+<168><252><181>c<166> > Attributes: > User-Name = "fred" > NAS-IP-Address = 10.22.11.200 > Called-Station-Id = "021d7e4b075b" > Calling-Station-Id = "001cb31669e8" > NAS-Identifier = "021d7e4b075b" > NAS-Port = 23 > Framed-MTU = 1400 > NAS-Port-Type = Wireless-IEEE-802-11 > EAP-Message = <2><0><0><9><1>fred > Message-Authenticator = > <174>%<152><208>=<195>(<201><139>[<29><228>f/<130><234> -- Heikki Vatiainen 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] DYNADDRESS and multiple Authby
On 01/18/2011 04:41 PM, Jim wrote: > I need to configure Radiator to allocate Dynamic IP's but we are already > using multiple AuthBy's with ContinueWhileReject. Our current handler > would be: > > > AuthByPolicy ContinueWhileReject > AuthBy LdapAuthenticator > AuthBy TooManyFail > > > Where if the request is rejected it will check the "TooManyFail" AuthBy > which connect the user in a walled garden if they have spammed too many > failed auths. > > Now for DYNADDRESS we would need to use ContinueWhileAccept instead > which would break our current TooManyFail auth check: > > > AuthByPolicy ContinueWhileAccept > AuthBy LdapAuthenticator > > AddressAllocator SQLAllocator > > Is the above example missing AuthBy TooManyFail? If I understood correctly, this TooManyFail is not going anywhere and the only change is that AuthBy DYNADDRESS, that works together with AuthBy LdapAuthenticator, is added. > How would I go about implementing Dynamic IP allocation and a 2nd authby > to return a generic walled garden answer when they have too many > failures? I was thinking either: My suggestion, based on my understanding of your situation, is this: AuthByPolicy ContinueWhileReject AuthByPolicy ContinueWhileAccept AuthBy LdapAuthenticator AddressAllocator SQLAllocator AuthBy TooManyFail How does this look like? > 1. Put a PostAuthHook or PostProcessingHook (not sure which) in our > current Realm which checks to see if the reply is an ACCEPT with no > Framed-IP-Address, and if so allocate a Dynamic IP. Would also require > config in accounting handler to deallocate IP. > > 2. Setup our realm as in the 2nd example and have a PostAuthHook or > PostProcessingHook which checks to see if the response is a REJECT. If > it is then check to see if they are in our 'badlist' and if so modify > the access response to an Accept with the walled garden attributes? > > Are both of these 2 solutions valid? If so what are your thoughts on > the them - is one much better than the other? I have not implemented > any hooks so far (or any Perl programming for that matter) so any advice > and pointers appreciated. I would first check groups and the possibilities group level policies offer. Thanks! Heikki -- Heikki Vatiainen 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] eap-ttls/ms-chap-v2
On 01/18/2011 05:19 PM, Michael Shoemaker wrote: > We are trying to get authentication with an alvarion wireless unit that > is sending mschapv2 encrypted passwords through a eap-ttls tunnel. > > I can get the eap-ttls tunnel built and can see the attempts to request > the mschapv2 but am not sure where our hangup is. I have a couple of suggestions below. If they do not work, reply with your configuration file (no secrets) and log file that shows the failing requests. > What needs to be done to be able to get local authentication on the > radiator server using AuthBy DBFILE (DB_File) > > The db was built using a plaintext file then converted using the > builddbm script. Did you use -t option with builddbm? If you did not, then you should remove "DBType DB_FILE" from the config. By default builddbm creates a AnyDBM_File which is also the default value for DBType. > > > > Filename /etc/raddb.proxy/dbm/users.db > DBType DB_File Check if this is really the correct value. > > this gets me to the point of doing the ttls tunnel, then it passes the > mschap stuff to the authby dbfile... but I am not sure how to unencrypt > the pw to check vs the db file. If the DBType check will not help, then the problems with password check should be visible in the log. Thanks! Heikki Vatiainen -- Heikki Vatiainen 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] eap-ttls/ms-chap-v2
On 01/18/2011 11:51 PM, Michael Shoemaker wrote: > Yes, I used the -t as I am working with a db compiled as such and can't > change that at this time. Ok. From the log it looks like Radiator can read the DBM file correctly. Please reply with the entry for user tonytestgordonlab from the original plain text user file. Since you are using MSCHAPv2, the User-Password needs to be in plain text or NTHash format. See the file called "users" in the top level of Radiator distribution directory. Check examples pwtest14 and pwtest15. > This is what is in the access request to the dbfile. > > > User-Name = "tonytestgordonlab" > MS-CHAP-Challenge = f<223>)<22><158>R\<27><3><5>ia<226><213>*n > MS-CHAP2-Response = > <193><0><0><0><0><27><0><0><0>P<24><7><0><1><0><0><0><0><0><0><0><0><0><0><0><0><229>[<149><185><148><25>I,D<250>KS<153><183><28>\ > -<209><18> <186><1><183> > > Fri Jan 14 12:44:56 2011: DEBUG: EAP TTLS inner authentication request > for tonytestgordonlab > Fri Jan 14 12:44:56 2011: DEBUG: Handling request with Handler > 'TunnelledByTTLS=1' > Fri Jan 14 12:44:56 2011: DEBUG: Rewrote user name to tonytestgordonlab > Fri Jan 14 12:44:56 2011: DEBUG: Deleting session for > tonytestgordonlab, 192.168.0.1, > Fri Jan 14 12:44:56 2011: DEBUG: Handling with Radius::AuthDBFILE: > Fri Jan 14 12:44:56 2011: DEBUG: Radius::AuthDBFILE looks for match with > tonytestgordonlab [tonytestgordonlab] > Fri Jan 14 12:44:57 2011: DEBUG: Radius::AuthDBFILE REJECT: Bad > Password: tonytestgordonlab [tonytestgordonlab] > Fri Jan 14 12:44:57 2011: DEBUG: AuthBy DBFILE result: REJECT, Bad Password > Fri Jan 14 12:44:57 2011: INFO: Access rejected for tonytestgordonlab: > Bad Password > Fri Jan 14 12:44:57 2011: DEBUG: Returned TTLS tunnelled Diameter Packet > dump: > > > That is what I have. I am quite sure I must be over looking something > fairly trivial. > > Thoughts? > > > On 01/18/2011 04:19 PM, Heikki Vatiainen wrote: >> On 01/18/2011 05:19 PM, Michael Shoemaker wrote: >> >>> We are trying to get authentication with an alvarion wireless unit that >>> is sending mschapv2 encrypted passwords through a eap-ttls tunnel. >>> >>> I can get the eap-ttls tunnel built and can see the attempts to request >>> the mschapv2 but am not sure where our hangup is. >> I have a couple of suggestions below. If they do not work, reply with >> your configuration file (no secrets) and log file that shows the failing >> requests. >> >>> What needs to be done to be able to get local authentication on the >>> radiator server using AuthBy DBFILE (DB_File) >>> >>> The db was built using a plaintext file then converted using the >>> builddbm script. >> Did you use -t option with builddbm? If you did not, then you should >> remove "DBType DB_FILE" from the config. By default builddbm creates a >> AnyDBM_File which is also the default value for DBType. >> >>> >>> >>> >>> Filename /etc/raddb.proxy/dbm/users.db >>> DBType DB_File >> Check if this is really the correct value. >> >>> >>> this gets me to the point of doing the ttls tunnel, then it passes the >>> mschap stuff to the authby dbfile... but I am not sure how to unencrypt >>> the pw to check vs the db file. >> If the DBType check will not help, then the problems with password check >> should be visible in the log. >> >> Thanks! >> Heikki Vatiainen >> -- Heikki Vatiainen 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] eap-ttls/ms-chap-v2
On 01/19/2011 12:10 AM, Michael Shoemaker wrote: > tonytestgordonlab User-Password = "testing123" > Service-Type = 2, > Ascend-Assign-IP-Pool = 0, > Ascend-Data-Filter = "ip in forward tcp est", > Ascend-Data-Filter = "ip in forward dstip xx", > Ascend-Data-Filter = "ip in drop tcp dstport = 25", > Ascend-Data-Filter = "ip in forward" The file contents look good. Since MSCHAPv2 uses the username for hashing, the server must calculate the hash from the exactly same username than client has. In other words, any sort of RewriteUsername Radiator does can cause incorrect results from MSCHAPv2. Please check your configuration for rewrites. To eliminate possible problem with DBFile, try also. If the problem does not go away, reply with: - Your configuration file (no securets) - Full log from failed attempt - Radiator version - What username the client uses - What the client software is (Alvarion, something else?) Thanks! > On 01/18/2011 05:03 PM, Heikki Vatiainen wrote: >> On 01/18/2011 11:51 PM, Michael Shoemaker wrote: >>> Yes, I used the -t as I am working with a db compiled as such and can't >>> change that at this time. >> Ok. From the log it looks like Radiator can read the DBM file correctly. >> Please reply with the entry for user tonytestgordonlab from the original >> plain text user file. >> >> Since you are using MSCHAPv2, the User-Password needs to be in plain >> text or NTHash format. See the file called "users" in the top level of >> Radiator distribution directory. Check examples pwtest14 and pwtest15. >> >>> This is what is in the access request to the dbfile. >>> >>> >>> User-Name = "tonytestgordonlab" >>> MS-CHAP-Challenge = f<223>)<22><158>R\<27><3><5>ia<226><213>*n >>> MS-CHAP2-Response = >>> <193><0><0><0><0><27><0><0><0>P<24><7><0><1><0><0><0><0><0><0><0><0><0><0><0><0><229>[<149><185><148><25>I,D<250>KS<153><183><28>\ >>> >>> -<209><18> <186><1><183> >>> >>> Fri Jan 14 12:44:56 2011: DEBUG: EAP TTLS inner authentication request >>> for tonytestgordonlab >>> Fri Jan 14 12:44:56 2011: DEBUG: Handling request with Handler >>> 'TunnelledByTTLS=1' >>> Fri Jan 14 12:44:56 2011: DEBUG: Rewrote user name to tonytestgordonlab >>> Fri Jan 14 12:44:56 2011: DEBUG: Deleting session for >>> tonytestgordonlab, 192.168.0.1, >>> Fri Jan 14 12:44:56 2011: DEBUG: Handling with Radius::AuthDBFILE: >>> Fri Jan 14 12:44:56 2011: DEBUG: Radius::AuthDBFILE looks for match with >>> tonytestgordonlab [tonytestgordonlab] >>> Fri Jan 14 12:44:57 2011: DEBUG: Radius::AuthDBFILE REJECT: Bad >>> Password: tonytestgordonlab [tonytestgordonlab] >>> Fri Jan 14 12:44:57 2011: DEBUG: AuthBy DBFILE result: REJECT, Bad >>> Password >>> Fri Jan 14 12:44:57 2011: INFO: Access rejected for tonytestgordonlab: >>> Bad Password >>> Fri Jan 14 12:44:57 2011: DEBUG: Returned TTLS tunnelled Diameter Packet >>> dump: >>> >>> >>> That is what I have. I am quite sure I must be over looking something >>> fairly trivial. >>> >>> Thoughts? >>> >>> >>> On 01/18/2011 04:19 PM, Heikki Vatiainen wrote: >>>> On 01/18/2011 05:19 PM, Michael Shoemaker wrote: >>>> >>>>> We are trying to get authentication with an alvarion wireless unit >>>>> that >>>>> is sending mschapv2 encrypted passwords through a eap-ttls tunnel. >>>>> >>>>> I can get the eap-ttls tunnel built and can see the attempts to >>>>> request >>>>> the mschapv2 but am not sure where our hangup is. >>>> I have a couple of suggestions below. If they do not work, reply with >>>> your configuration file (no secrets) and log file that shows the >>>> failing >>>> requests. >>>> >>>>> What needs to be done to be able to get local authentication on the >>>>> radiator server using AuthBy DBFILE (DB_File) >>>>> >>>>> The db was built using a plaintext file then converted using the >>>>> builddbm script. >>>> Did you use -t option with builddbm?
Re: [RADIATOR] Issues with Tacacs/Radius and v6 conversion
On 01/26/2011 03:07 PM, Patrik Forsberg wrote: > I've recently tried to get a new radiator enviroment working with FreeBSD > 8.1, Perl 5.10 and Radiator 4.7 with current patches. > > Most stuff work as expected but I've ran into a small snag with my setup. I > need to use a Handler to catch Calling-Station-Id but for some reason all > Calling-Station-Id that end up in accounting and level 4 logs begin there ip > with ":::". The only IPs that exist on the machine are ipv4. > For some reason the Calling-Station-Id field becomes to short to handle this > and up with something like " :::111.11.1 " <-- this is the correct number > of characters replaced with 1s to protect internal information. > I've only been able to verify this issue with Tacacs so far.. maybe it's > different with Radius calls. Is this pure RADIUS or something that has been converted from TACACS+? The ::: prefix belongs to the "IPv4-Mapped IPv6 Address" format. Socket interfaces can use this format to hand IPv4 addresses to applications that only know about IPv6. http://tools.ietf.org/html/rfc4291#section-2.5.5 RFC 4038 and http://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 tell more. You may have already known this, but I thought I'd mention it anyways. > Only place I could find a reference to ":::" is in Util.pm and that was > just to figure out if a conversion function were handling a v4 or v6 address.. Yes, this is how Radiator extracts the IPv4 address from a mapped format when the address looks like IPv6 but what is on the wire is really IPv4. It is not the cause for the behaviour you report. > The same issue appear in Level 4 trace with tacacs > Example > " > Wed Jan 11 11:12:13 2011: DEBUG: TacacsplusConnection Authorization REQUEST > 6, 15, 1, 1, scrambled, telnet111, :::111.11.1, 2, service=shell cmd= > " > > So I'm guessing it has to do with Tacacs not radius ? Well, it depends :) This line indicates that the mapped address had been packed in the incoming Tacacs request that is just being handled. So it looks like some entity is creating Tacacs requests that contain IPv4-Mapped IPv6 Addresses. Can you describe your setup and environment a little better. What device is creating Tacacs messages, please post your configuration (no secrets) and more complete log entries that show how messages are handled, especially those that contain the ::: prefix. > Anyone else seen this or have it working somewhere that doesn't show this ? > > Perhaps a fix ? A fix might involve checking AI_V4MAPPED related socket options, as specified by RFC 3493, but if you could provide more information abouth e.g., the Tacacs message sender, that would help to tell if the fix is needed by Radiator or something else. Socket interfaces have implementation specific differences and this is one of those "interesting" areas :) So please tell us more, your configuration, log snippet and general setup would be very useful. -- Heikki Vatiainen 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] Issues with Tacacs/Radius and v6 conversion
On 01/26/2011 05:08 PM, Patrik Forsberg wrote:
>> Is this pure RADIUS or something that has been converted from TACACS+?
>
> From what I can tell it's only on Tacacs+ messages, but as I mentioned
> before, I haven't seen it on Radius yet but that doesn't mean that its not
> the same there.
> It's pretty strait forward, I think. We have a Extreme and a Brocade(Foundry)
> device that try to authenticate a user on the tacacs server running in
> Radiator.
> Config for the extreme is as follows
> "
> configure tacacs primary shared-secret
> configure tacacs primary server client-ip vr
> configure tacacs-accounting primary shared-secret
As an additional test, can you try unencyprted configuration and use
e.g., Wireshark to see the Tacacs+ message when it is received from the
network. Message fields user, port, remote address and arguments are in
that order and are all ASCII strings. If you see the same ::: prefix
there, then you may want to contact the switch vendor.
> The Brocade have a similar configuration ofc :)
About this ::: problem: do you see it with both Extreme and Brocade?
> Radiator is almost as simple but simply to many rows to paste in here.. but
> it's pretty much the same as in the example configurations from "goodies"..
> and as far as authentication goes it's working as intended.
Ok.
> Trace 4 log
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection result Access-Accept
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authentication REPLY 1,
> 0, ,
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection disconnected from
> 111.11.111.111:34801
> Wed Jan 26 15:55:43 2011: DEBUG: New TacacsplusConnection created for
> 111.11.111.111:41205
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection request 192, 2, 1, 0,
> 1763071228, 57
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authorization REQUEST
> 6, 15, 1, 1, , telnet175, :::111.11.1, 2, service=shell cmd=
Thanks for the log. Username (), port (telnet175), rem_addr
(:::111.11.1) and arguments (service=shell cmd=) are all ASCII
strings that follow each other directly in the message body.
Based on this the original message Radiator receives from Extreme or
Brocade seems to have incorrect information for rem_addr. There seems to
be enough space for a full length IP address (aaa.bbb.ccc.ddd) but
there's not enough of original IP left so that it can e.g., be rewritten
with Radiator.
The same seems to happen with Accounting REQUEST as shown below.
It would be interesting to see any results from Wireshark. That would
confirm the suspicion that the received message is not quite right.
You could rewrite the Calling-Station-Id with Radiator, but I guess
there is not enough information in the ::: prefixed address, is there?
> Wed Jan 26 15:55:43 2011: DEBUG: AuthorizeGroup rule match found: permit
> service=shell cmd= { priv-lvl=15 }
> Wed Jan 26 15:55:43 2011: INFO: Authorization permitted for at
> 111.11.111.111, group manager, args service=shell cmd=
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Authorization RESPONSE
> 1, , , priv-lvl=15 priv-lvl=15
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection disconnected from
> 111.11.111.111:41205
> Wed Jan 26 15:55:43 2011: DEBUG: New TacacsplusConnection created for
> 111.11.111.111:60789
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection request 192, 3, 1, 0,
> 1553834616, 75
> Wed Jan 26 15:55:43 2011: DEBUG: TacacsplusConnection Accounting REQUEST 2,
> 6, 15, 1, 1, , telnet175, :::111.11.1, 2, start_time=1296053322
> service=shell
> Wed Jan 26 15:55:43 2011: DEBUG: TACACSPLUS derived Radius request packet
> dump:
> Code: Accounting-Request
> Identifier: UNDEF
> Authentic:
> Attributes:
> NAS-IP-Address = 111.11.111.111
> NAS-Port-Id = "telnet175"
> Calling-Station-Id = ":::111.11.1"
> NAS-Identifier = "TACACS"
> User-Name = ""
> Acct-Status-Type = Start
> Acct-Session-Id = "1553834616"
> cisco-avpair = "start_time=1296053322"
> cisco-avpair = "service=shell"
> OSC-Version-Identifier = "192"
> The the log.. snipped out a few things and changed the ip to 111s ;)
Ok.
> As far as I can tell the rem_addr is getting limited by rem_addr_len in
> ServerTACACS.pm .. but that in it self might not be it ?
I'm not sure what you mean, but since they are ASCII strings the :::
does not look like error in offset while decoding.
> Did a Trace 5 dump too.. but that doesn't seem to reveal anything that the
> trace 4 dump doesn't.
Trace 5 dump should show what the message
Re: [RADIATOR] Accounting process dying
On 01/27/2011 05:48 PM, Jim wrote:
> We are running separate processes for Radius accounting and
> authentication, and each is running with 'FarmSize 4'. For the
> accounting I'm seeing:
>
> Thu Jan 27 15:04:57 2011: WARNING: Server farm process 31432 died,
> restarting
> Thu Jan 27 15:04:57 2011: DEBUG: Forking server farm instance 1
Thanks for your report.
Can you tell more about your operating environment? What is your
Radiator version, does it have patches, what is your operating system,
is it 64bit or 32bit, what is the load level when you see restarts, is
the memory usage starting to reach system limits etc.
If you are running Linux, does dmesg command show anything special e.g.,
out of memory messages? Do system logs show anything peculiar from the
time the crash happens?
> The logfile for instance 1 at Trace 4 doesnt show any errors around this
> time, the last thing in the log was a SQL update at ('Thu Jan 27
> 15:04:51 2011: DEBUG: do query is: 'UPDATE.'). How can I see what
> is causing this process to die? I suspect its related to the SQL
> updates in some way as the authentication process doesn't suffer this
> issue and doesn't log anything to SQL.
If you already have Trace 4 enabled and there is nothing in logs, it is
hard to say. As I wrote above, can you tell e.g., if you are not running
out of memory when the process dies.
> Is it possible to either include the process ID in the logfile name, or
> within the logging itself so that I can easily see where and when a
> process has stopped and what the last accounting action was?
Currently there is no such method. If you take a look at Radius/Log.pm
and sub main::log function, you could add this
$s = "PID:$$ $s";
just before the comment "Catch recursion".
After that all log messages will contain the process ID.
--
Heikki Vatiainen
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] Radiator unable to talk to database
On 01/31/2011 07:39 AM, Zaeem Arshad wrote: > We are running Radiator 4.5.1 on RHEL 4.8 kernel 2.6.9-89. Radiator > talks to a backend Oracle 10G server. Recently, we ran into an issue > where Radiator just could not talk to the database and logged this message: > > Sat Jan 22 04:57:16 2011: ERR: Could not connect to SQL database with > DBI->connect > dbi:Oracle:(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.x.x)(PORT= > 1533))(CONNECT_DATA=(SID=db123))), db123, db123: > Sat Jan 22 04:57:16 2011: ERR: Could not connect to any SQL database. > Request is ignored. Backing off for 600 seconds > > By the look of it, it appeared to be a connectivity/database issue. It does. You did not mention if the Oracle logs showed anything out of ordinary happening at the same time. If the log is still available, that might one place to check why Radiator had problems. > However, the network connectivity was up and we could reach the database > using Oracle client from the same machine. We suspected the JDBC drivers > and wrote a separate java program using the same driver and environment > variables and it connected to the database just fine. During this > period, Radiator kept logging the above mentioned message. Multiple > process restarts and a server reboot did not fix the issue. At least the reboot should have taken care of any possible host IP stack problems. > Our Radiator installation is configured to log the messages to > /var/log/radius/radiator.log rotated manually. The log file's size was > around 270MB at the time of the problem. I moved the logfile and created > a new one and restarted the Radiator process and everything started > working fine. The log file's size is currently 356MB and the server is > running fine. Is this a bug or a known issue? It is not a known issue. There should not be any connection between log file size and db problems especially if disk space was not a problem. Can you check Oracle logs if for example, there were connectivity errors which caused oracle to put Radiator on hold for a certain time. Those errors might have happened before Radiator started logging the connectivity problems shown above. Thanks for reporting this. Please let us know if you find more information about what happened or if the problem happens again. Thanks! -- Heikki Vatiainen 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] Assigning IP's directly from the Radius server
On 01/31/2011 11:46 AM, Gerard Alcorlo Bofill wrote: > I'm using Radiator with 4 CISCO AP 1100 to offer Eduroam access. > Nowadays we are giving IP address from a DHCP server without visibility > with the Radius. > I'd like to query the Radius using radwho.cgi script giving all the > assignated IP addresses at that specific moment. > > To do that, I thought that the solution would be to use > and then use the Framed-Route attribute to assign > the gateway to the clients. > > Am I right? You should experiment and see if this works for you. Have you checked how AP 1100 relays the IP address to your eduroam users? The users are most likely using DHCP, so Aironet AP should be able to answer DHCP queries. I have not checked if they have this functionality, so please let us know how it works. Michael already provided a good look at SQL allocator, and you may also want to check goodies/addressallocator.cfg for another example. > I also have problems understanding the clause. > In what situation is useful that Radiator asks the IP to a real DHCP > server? Is something related to the performance or there are situations > that need a DHCP mandatorily? I think there are multiple cases which can be useful. For example: - checking address consumption centrally from DHCP - having one centralised system for address management - using DHCP server to trigger firewall or other rules The first two points relate to keeping track of address usage. The second could be used as an extra security measure where all users are forced to use dhcp before they are allowed to use the network. This can keep users from configuring static addresses to try to hide their activities. -- Heikki Vatiainen 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] PEAP Issue
t>" > NAS-IP-Address = 127.0.0.1 > Calling-Station-Id = "02-00-00-00-00-01" > Framed-MTU = 1400 > NAS-Port-Type = Wireless-IEEE-802-11 > Connect-Info = "JANET Roaming test" > EAP-Message = <2><4><0><6><25><1> > Message-Authenticator = > <151><11><9><208>f<168><228>]MC<15><128><250><144><223><241> > Proxy-State = OSC-Extended-Id=79 > > Tue Feb 1 11:26:50 2011: DEBUG: Handling request with Handler 'Realm = > dev.ja.net', Identifier '' > Tue Feb 1 11:26:50 2011: DEBUG: Deleting session for > j...@dev.ja.net<mailto:j...@dev.ja.net>, 127.0.0.1, > Tue Feb 1 11:26:50 2011: DEBUG: Handling with Radius::AuthNTLM: > Tue Feb 1 11:26:50 2011: DEBUG: Handling with EAP: code 2, 4, 6, 25 > Tue Feb 1 11:26:50 2011: DEBUG: Response type 25 > Tue Feb 1 11:26:50 2011: DEBUG: EAP result: 3, EAP PEAP Challenge > Tue Feb 1 11:26:50 2011: DEBUG: AuthBy NTLM result: CHALLENGE, EAP PEAP > Challenge > Tue Feb 1 11:26:50 2011: DEBUG: Access challenged for > j...@dev.ja.net<mailto:j...@dev.ja.net>: EAP PEAP Challenge > Tue Feb 1 11:26:50 2011: DEBUG: Packet dump: > *** Sending to 194.82.174.185 port 63780 > Code: Access-Challenge > Identifier: 79 > Authentic: <202>W7t<241><214><201>lq<26><231><236><149><152><146><234> > Attributes: > EAP-Message = <1><5><0>+<25><1><23><3><1><0> > <4><131><135><207><180>DK<168><212><230>'<183><134><178><202>:<146>K<26><178><194><177><12><203>50<185>F<31>0<201><238> > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > Proxy-State = OSC-Extended-Id=79 > > Tue Feb 1 11:26:50 2011: DEBUG: Packet dump: > *** Received from 194.82.174.185 port 63780 > Code: Access-Request > Identifier: 80 > Authentic: .<4><220><255><234>X<213>lEB<234><176>Y<228><164>A > Attributes: > User-Name = "j...@dev.ja.net<mailto:j...@dev.ja.net>" > NAS-IP-Address = 127.0.0.1 > Calling-Station-Id = "02-00-00-00-00-01" > Framed-MTU = 1400 > NAS-Port-Type = Wireless-IEEE-802-11 > Connect-Info = "JANET Roaming test" > EAP-Message = <2><5><0>`<25><1><23><3><1><0> > <154>ut<138>pwf<218>gf:4bm9P<191><128><24><144><240>U<153>I<199><201><224><220><137><185><6>S<23><3><1><0>0<6>Q<27><22>:*<176>@<185><26><143><209><185>_<8><212>|<14><172><138><173><242>q<161><31>QT;&<149>@"<149><3>S<147><244><139><235><133>1<157><211>o<26><220><170><233> > Message-Authenticator = > <221>\#A<169>J<142><192>F<145><164>S<137><154><199><13> > Proxy-State = OSC-Extended-Id=80 > > Tue Feb 1 11:26:50 2011: DEBUG: Handling request with Handler 'Realm = > dev.ja.net', Identifier '' > Tue Feb 1 11:26:50 2011: DEBUG: Deleting session for > j...@dev.ja.net<mailto:j...@dev.ja.net>, 127.0.0.1, > Tue Feb 1 11:26:50 2011: DEBUG: Handling with Radius::AuthNTLM: > Tue Feb 1 11:26:50 2011: DEBUG: Handling with EAP: code 2, 5, 96, 25 > Tue Feb 1 11:26:50 2011: DEBUG: Response type 25 > Tue Feb 1 11:26:50 2011: DEBUG: EAP PEAP inner authentication request for > anonymous > Tue Feb 1 11:26:50 2011: DEBUG: PEAP Tunnelled request Packet dump: > Code: Access-Request > Identifier: UNDEF > Authentic: <216><183><31><249><161><145>zv<195><31>bLY<139><23>o > Attributes: > EAP-Message = <2><0><0><19><1>j...@dev.ja.net<mailto:j...@dev.ja.net> > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > NAS-IP-Address = 127.0.0.1 > Calling-Station-Id = "02-00-00-00-00-01" > User-Name = "anonymous" > > Tue Feb 1 11:26:50 2011: DEBUG: Handling request with Handler > 'TunnelledByPEAP = 1', Identifier '' > Tue Feb 1 11:26:50 2011: DEBUG: Deleting session for anonymous, 127.0.0.1, > Tue Feb 1 11:26:50 2011: DEBUG: Handling with Radius::AuthNTLM: > Tue Feb 1 11:26:50 2011: DEBUG: Handling with EAP: code 2, 0, 19, 1 > Tue Feb 1 11:26:50 2011: DEBUG: Response type 1 > Tue Feb 1 11:26:50 2011: DEBUG: EAP result: 3, EAP PEAP Challenge > Tue Feb 1 11:26:50 2011: DEBUG: AuthBy NTLM result: CHALLENGE, EAP PEAP > Challenge > Tue Feb 1 11:26:50 2011: DEBUG: Access challenged for anonymous: EAP PEAP > Challenge > Tue Feb 1 11:26:50 2011: DEBUG: Returned PEAP tunnelled packet dump: > Code: Access-Challenge > Identifier: UNDEF > Authentic: <216><183><31><249><161><145>zv<195><31>bLY<139><23>o > Attributes: > EAP-Message = <1><1><0><6><25>! > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > > Tue Feb 1 11:26:50 2011: DEBUG: EAP result: 3, EAP PEAP inner authentication > redispatched to a Handler > Tue Feb 1 11:26:50 2011: DEBUG: AuthBy NTLM result: CHALLENGE, EAP PEAP > inner authentication redispatched to a Handler > Tue Feb 1 11:26:50 2011: DEBUG: Access challenged for > j...@dev.ja.net<mailto:j...@dev.ja.net>: EAP PEAP inner authentication > redispatched to a Handler > Tue Feb 1 11:26:50 2011: DEBUG: Packet dump: > *** Sending to 194.82.174.185 port 63780 > Code: Access-Challenge > Identifier: 80 > Authentic: (qU<214>X<229>4<192>G<161>e<242><21><179>5\ > Attributes: > EAP-Message = <1><6><0>+<25><1><23><3><1><0> > <150><137><249><202><150><173><229><135>&i<182><169>X<198><15>><177>-`<202>NV/<138>hG|<14><204><207><241><128> > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > Proxy-State = OSC-Extended-Id=80 > > Tue Feb 1 11:26:50 2011: DEBUG: Packet dump: > *** Received from 194.82.174.185 port 63780 > Code: Access-Request > Identifier: 81 > Authentic: X;w<25><10><162><128>,<2>nJ<21><180><160><177><178> > Attributes: > User-Name = "j...@dev.ja.net<mailto:j...@dev.ja.net>" > NAS-IP-Address = 127.0.0.1 > Calling-Station-Id = "02-00-00-00-00-01" > Framed-MTU = 1400 > NAS-Port-Type = Wireless-IEEE-802-11 > Connect-Info = "JANET Roaming test" > EAP-Message = <2><6><0>P<25><1><23><3><1><0> > <231><201>o0\<145><8><216>)j<254>|<183><234>&<140><11>B$<174><8>p<221><204><163><239><180><128><191>`<208><245><23><3><1><0> > > <200><5><11><131><18>U:<232>%gZ<236><25><244><215>+<148><158><200>n<255><147><215><23><201>t2<211>.<149>5<171> > Message-Authenticator = |<9>:<11><137>$i<221><137>"<135><171><22>$x<21> > Proxy-State = OSC-Extended-Id=81 > > Tue Feb 1 11:26:50 2011: DEBUG: Handling request with Handler 'Realm = > dev.ja.net', Identifier '' > Tue Feb 1 11:26:50 2011: DEBUG: Deleting session for > j...@dev.ja.net<mailto:j...@dev.ja.net>, 127.0.0.1, > Tue Feb 1 11:26:50 2011: DEBUG: Handling with Radius::AuthNTLM: > Tue Feb 1 11:26:50 2011: DEBUG: Handling with EAP: code 2, 6, 80, 25 > Tue Feb 1 11:26:50 2011: DEBUG: Response type 25 > Tue Feb 1 11:26:50 2011: DEBUG: EAP PEAP inner authentication request for > anonymous > Tue Feb 1 11:26:50 2011: DEBUG: PEAP Tunnelled request Packet dump: > Code: Access-Request > Identifier: UNDEF > Authentic: Q<187><20><21>I<198><218>+w<251><149><6><7>K<183>& > Attributes: > EAP-Message = <2><1><0><10><3><4><26><6><5><17> > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > NAS-IP-Address = 127.0.0.1 > Calling-Station-Id = "02-00-00-00-00-01" > User-Name = "anonymous" > > Tue Feb 1 11:26:50 2011: DEBUG: Handling request with Handler > 'TunnelledByPEAP = 1', Identifier '' > Tue Feb 1 11:26:50 2011: DEBUG: Deleting session for anonymous, 127.0.0.1, > Tue Feb 1 11:26:50 2011: DEBUG: Handling with Radius::AuthNTLM: > Tue Feb 1 11:26:50 2011: DEBUG: Handling with EAP: code 2, 1, 10, 3 > Tue Feb 1 11:26:50 2011: DEBUG: Response type 3 > Tue Feb 1 11:26:50 2011: DEBUG: EAP Nak desires type 4 > Tue Feb 1 11:26:50 2011: DEBUG: EAP result: 1, Desired EAP type > MD5-Challenge (4) not permitted > Tue Feb 1 11:26:50 2011: DEBUG: AuthBy NTLM result: REJECT, Desired EAP type > MD5-Challenge (4) not permitted > Tue Feb 1 11:26:50 2011: INFO: Access rejected for anonymous: Desired EAP > type MD5-Challenge (4) not permitted > Tue Feb 1 11:26:50 2011: DEBUG: Returned PEAP tunnelled packet dump: > Code: Access-Reject > Identifier: UNDEF > Authentic: Q<187><20><21>I<198><218>+w<251><149><6><7>K<183>& > Attributes: > Reply-Message = "Desired EAP type MD5-Challenge (4) not permitted" > > Tue Feb 1 11:26:50 2011: DEBUG: EAP result: 3, EAP PEAP inner authentication > redispatched to a Handler > Tue Feb 1 11:26:50 2011: DEBUG: AuthBy NTLM result: CHALLENGE, EAP PEAP > inner authentication redispatched to a Handler > Tue Feb 1 11:26:50 2011: DEBUG: Access challenged for > j...@dev.ja.net<mailto:j...@dev.ja.net>: EAP PEAP inner authentication > redispatched to a Handler > Tue Feb 1 11:26:50 2011: DEBUG: Packet dump: > *** Sending to 194.82.174.185 port 63780 > Code: Access-Challenge > Identifier: 81 > Authentic: '9<220><197>I<182><29>whiv"@<9>l<191> > Attributes: > EAP-Message = <1><7><0>+<25><1><23><3><1><0> > <239>'%9t]<3><25><141><177><144><10>U@<195><27><160><227>2<217>'<166><237>J<131>z<134>.4<6><192><154> > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > Proxy-State = OSC-Extended-Id=81 > > Tue Feb 1 11:26:51 2011: DEBUG: Packet dump: > *** Received from 194.82.174.185 port 63780 > Code: Access-Request > Identifier: 82 > Authentic: <25>j<254>e<198>Ul<17><244><203><197><174><1><166><183><131> > Attributes: > User-Name = "j...@dev.ja.net<mailto:j...@dev.ja.net>" > NAS-IP-Address = 127.0.0.1 > Calling-Station-Id = "02-00-00-00-00-01" > Framed-MTU = 1400 > NAS-Port-Type = Wireless-IEEE-802-11 > Connect-Info = "JANET Roaming test" > EAP-Message = <2><7><0>P<25><1><23><3><1><0> > <224><2>t<159><193><252><178><244>&<247><217><194>Z<15><211><203><4><186><18><170><210>.}<207><160><255><250><20><2><147>n_<23><3><1><0> > > <138><132><130><191>`[P<237><154>:<<11><239>K<215><3><31><153>u<192><20><244>Z<19>}<8><4>8rA<134><173> > Message-Authenticator = > <169><180><28><188>3<230><153>"<241><220><141><138><19>N<20><144> > Proxy-State = OSC-Extended-Id=82 > > Tue Feb 1 11:26:51 2011: DEBUG: Handling request with Handler 'Realm = > dev.ja.net', Identifier '' > Tue Feb 1 11:26:51 2011: DEBUG: Deleting session for > j...@dev.ja.net<mailto:j...@dev.ja.net>, 127.0.0.1, > Tue Feb 1 11:26:51 2011: DEBUG: Handling with Radius::AuthNTLM: > Tue Feb 1 11:26:51 2011: DEBUG: Handling with EAP: code 2, 7, 80, 25 > Tue Feb 1 11:26:51 2011: DEBUG: Response type 25 > Tue Feb 1 11:26:51 2011: DEBUG: EAP result: 1, PEAP Authentication Failure > Tue Feb 1 11:26:51 2011: DEBUG: AuthBy NTLM result: REJECT, PEAP > Authentication Failure > Tue Feb 1 11:26:51 2011: INFO: Access rejected for > j...@dev.ja.net<mailto:j...@dev.ja.net>: PEAP Authentication Failure > Tue Feb 1 11:26:51 2011: DEBUG: Packet dump: > *** Sending to 194.82.174.185 port 63780 > Code: Access-Reject > Identifier: 82 > Authentic: <24>4<157>i2<12>4s<200>7<1>YdZQ<162> > Attributes: > EAP-Message = <4><7><0><4> > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > Reply-Message = "PEAP Authentication Failure" > Proxy-State = OSC-Extended-Id=82 > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] PEAP Issue
On 02/01/2011 07:11 PM, Adam Bishop wrote: > OK, the issue is fixed in SAMBA 3.5.6. Good to hear. > It's a horrible, dirty fix, but to get 3.5.6 into 10.04 quickly: > > 0) Back up smb.conf > > 1) # aptitude purge samba winbind samba-common > > 2) add these 2 lines to /etc/apt/sources.lst > deb http://gb.archive.ubuntu.com/ubuntu/ natty main restricted > deb-src http://gb.archive.ubuntu.com/ubuntu/ natty main restricted > > > 3) # aptitude update > > 4) # aptitude install samba winbind Unless you need nmbd and smbd, you can install just samba-common and winbind. Then you do not have to worry about nmbd and smbd listening for incoming connections or broadcasting into your network. This samba issue affects Debian 5.0 too, and I know one setup where the server is up-to-date Debian 5.0 but samba-common and winbind are from 4.0. Radiator + ntlm_auth work happily and seem not to miss smbd or nmbd. The nice thing about winbind is it does not listen to any sockets for incoming connections and it or ntlm_auth do not need the other samba daemons. Well, at least with Debian 4.0 that was the case. Hopefully Samba and Debian/Ubuntu packages still support this. > 5) replace smb.conf > > 6) reboot / restart smbd / nmbd / winbind > > 7) remove the two lines from /etc/apt/sources.lst > > After this, you will need to keep an eye on the ubuntu repository for > security updates - as the packages have been pulled from a different > repository they will not be updated automatically. > > If an update is required, add the two lines again and do: > # aptitude update > # aptitude install samba winbind > > When natty hits stable (some time in april?) I'll make a back port request > for samba, so 3.5.6 might get included in the back ports repository. -- Heikki Vatiainen 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] Assigning IP's directly from the Radius server
On 02/03/2011 06:55 PM, Michael wrote: > oh and keep in mind, when you restart radiator, or even maybe reload > radiator, the AddressPool may re-mark all ips as available, therefore it may > hand out an IP that is already in use. Maybe someone else can confirm that > is correct? During restart and reload Radiator will run ReclaimQuery. Then it sets the timer to run ReclaimQuery after every LeaseReclaimInterval which defaults to one day. It will only mark those addresses available that had expired after the ReclaimQuery was last run. In other words, it will not mark all addresses available unless they had all expired. When Radiator starts, it will first check that all addresses in configuration belong to pool and then expired leases get reclaimed. The log shows something like this: ... Lots of Checking address lines ... Fri Feb 4 10:52:49 2011: DEBUG: Checking address 192.2.2.99 Fri Feb 4 10:52:49 2011: DEBUG: Query is: 'select STATE from RADPOOL where YIADDR='192.2.2.99'': Fri Feb 4 10:52:49 2011: DEBUG: Reclaiming expired leases Fri Feb 4 10:52:49 2011: DEBUG: do query is: 'update RADPOOL set STATE=0 where STATE!=0 and EXPIRY < 1296816769': Fri Feb 4 10:52:49 2011: DEBUG: Finished reading configuration file 'addressallocator.cfg' 1296816769 is the unix timestamp for Fri, 04 Feb 2011 10:52:49 GMT -- Heikki Vatiainen 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] Assigning IP's directly from the Radius server
On 02/04/2011 09:28 AM, Gerard Alcorlo Bofill wrote:
Gerard, if I understand correctly, the address allocator works, but you
have problems getting the wireless AP to accept the IP address you want
the wireless client to use.
> *** Sending to 192.168.50.9 port 1645
> Code: Access-Accept
> Identifier: 208
> Authentic: L$<158><20>#x<233>V<147>3<204>{<161><22>sj
> Attributes:
> Framed-IP-Netmask = xxx.xxx.xxx.xxx
> Framed-IP-Address = xxx.xxx.xxx.xxx
> MS-Primary-DNS-Server = xxx.xxx.xxx.xxx
> MS-Secondary-DNS-Server = xxx.xxx.xxx.xxx
> MS-MPPE-Send-Key = blablabla
> MS-MPPE-Recv-Key = blablabla
> EAP-Message = blablabla
> Message-Authenticator = blablabla
You may want to check the incoming Access-Request to see if there are
any Framed-* attributes. For example if Framed-Protocol is sent by the
WLAN AP, it may want to see Framed-Protocol in the response. What it
does with these attributes should be documented by the vendor.
>>>> This is the error I'm getting from de AP:
>>>> 16:27:29.234 GMT: RADIUS/DECODE: EAP-Message fragments, 6, total 6 bytes
>>>> 16:27:29.241 GMT: RADIUS/ENCODE(002A):Orig. component type = DOT11
>>>> 16:27:29.241 GMT: RADIUS/ENCODE: No idb found! Framed IP Addr might not
>>>> be included
>>>>
>>>> I thought that my NAS (my AP) would send all the attributes to the wifi
>>>> client but that's not happening.
>>>>
>>>> Are this attributes only for PPP connections or is it possible to use
>>>> them using a wifi AP?
I would say the Framed-* attributes are for connections such as PPP or
PPPoE. Have you found out how you can transfer the IP address the WLAN
AP receives to the Wireless user? It would be interesting to hear if
there is a method to do that.
The usual case with WPA-Enterprise is that the authentication completes
first and the client has then access to the network so it can query the
DHCP server. I guess this is what you had first place.
There is one hack that might be possible: configure WPA-Enterprise
authentication as it is normally done. Configure your DHCP server so
that it always asks RADIUS for IP addresses. I think this is technically
possible, but a good questions is does it make any sense :)
--
Heikki Vatiainen
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] ldap + starttls fails
On 02/06/2011 09:20 PM, James wrote: > I'm having some issues getting Radiator to bounce off of an LDAP > server with STARTTLS. Note that authentication works fine if I disable > both SSL and STARTTLS against my OpenDS LDAP server. The config below does client-authentiated TLS handshake. That is, both the client and server exchange certificates. If you only want to verify the server certificate, remove SSLCAClientKey and SSLCAClientCert from your config. A common configuration is for the client to verify server certificate against CA certificate in SSLCAFile and then authenticate to the LDAP server with AuthDN and AuthPassword. Please note that the SSLCA* settings are only for brining up the TLS/SSL connection. They have nothing to do with authenticating Radiator to the LDAP server. > Here's the snippet of configuration used for : > > > Identifier ldapAuth > Host server.example.com > BaseDN > UsernameAttruid > HoldServerConnection > UseTLS > SSLCAClientCert certificates/client.cert.pem > SSLCAClientKey certificates/client.key.pem Remove these two lines above, unless you really want to do client-authenticated TLS handshake. > SSLCAFile certificates/ca.cert.pem > Version 3 > > > The client certificates (client.cert.pem and client.key.pem) were > generated by a CA I runrun, and the ca.cert.pem is actually a > self-signed certificate that I obtained by doing an "openssl s_client > -connect server.example.com:636". (the STARTTLS and SSL certificates > are identical on the LDAP server) > > When I enable UseTLS connectivity fails with the following error messages: > > > Sun Feb 6 10:14:17 2011: DEBUG: Handling with Radius::AuthLDAP2: ldapAuth > Sun Feb 6 10:14:17 2011: INFO: Connecting to server.example.com:389 > Sun Feb 6 10:14:17 2011: ERR: StartTLS failed: SSL connect attempt > failed because of handshake > problemserror::lib(0):func(0):reason(0) > Sun Feb 6 10:14:17 2011: ERR: Could not open LDAP connection to > server.example.com:389. Backing off for 600 seconds. > Sun Feb 6 10:14:17 2011: DEBUG: AuthBy LDAP2 result: IGNORE, User > database access error > > > I did a bit of digging -- seems it's possible to disable certificate > checking in Net::LDAP (although clearly not recommended). I modified > the Ldap.pm file and changed the SSLVerify var from required to none; > the exact same error still occurs. This doesn't make sense to me. The > error should likely disappear if I've set "verify" to "none," no? > > My goal is ultimately to change SSLCAFile to the self-signed > certificate (gleaned from an "openssl s_client -connect"). Any > thoughts on how to go about fixing this? > > Thanks! > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] timing ldap auth
On 02/07/2011 08:32 AM, Barry Ard wrote: > I would like to be track / report on the success/failure of the our > LDAP2 AuthBy's. I am particularly interested in catching timeouts and > connection failures as these requests are made to machines in a > different part of our organization and we have been having issues. You should already see LDAP connection related messages if you have at least Trace 3 enabled. For example, server side disconnects, Radiator initiated reconnects and successful TLS connection establishments are logged with LOG_INFO level (3). More serious messages cause a LOG_WARNING or LOG_ERR and will be logged with Trace 3 too. An example of LOG_ERR event is unsuccessful LDAP connection attempt during reconnect. > I was looking at using a PostSearchHook but a quick glance at > AuthLDAP2.pm it looks to be called after a successful auth (thus not > catching connection failures), is this correct? If so, what would be > the best way to go about this? PostSearchHook only runs if the search was successful, so this does not sound like what you are after. Do you think Trace 3 is not enough? It should already show many connection related events. -- Heikki Vatiainen 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] timing ldap auth
On 02/08/2011 01:49 AM, Barry Ard wrote: > I would like to be graph the results (number of timeouts and length of time > to do ldap lookup) so I don't know if the log info would work very well. For timing you could try PostSearchHook. The current request has a record for arrival time in seconds and microseconds. You could then compare the current time against these timestamps and see at least how long it took for the request to get to the Hook. If Radiator can be considered as fast and LDAP search as slow, this can give an idea of how long the search took. Grep for timeInterval to see how these time stamps are used by Radiator. For graphing timeouts, you may have to grep the log and the process the results for data that can be graphed. There is also the statistics from , but this may be more useful of seeing which AuthBys were used if you have many for error fallback purposes. -- Heikki Vatiainen 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] 3 Quick Assorted Queries
On 02/09/2011 05:37 PM, Adam Bishop wrote: > * Can I disable PAP? You can not stop client sending User-Password attribute, but you can create a handler that rejects the request if the attribute is present. That could direct the users to move e.g. from TTLS/PAP to TTLS/MSCHAPv2 or something else that does not cause passwords to be logged with Trace 4. > * Using fork with AuthByNTLM causes the request to fail: > > Wed Feb 9 15:22:24 2011: DEBUG: Handling with Radius::AuthNTLM: Wed Feb 9 > 15:22:24 2011: DEBUG: AuthBy NTLM result: IGNORE, forked > > Anyone used fork with NTLM? This does not look like failure to me. This is logged by the parent meanwhile the newly forked child is handling the request. The real result should come from the child process once it finishes. You should see messages from the child in the logs while it does NTLM authentication. Why would you need to use fork with NTLM? > * What do I need to do to get these types of accounting requests handled? > The standard user accounting packets are handled fine, but the NAS status > updates aren't: Just guessing here, but if you use Handlers that try to match realms there is no User-Name where the realm comes from. You could try a Handler that has Request-Type = Accounting-Request, Acct-Status-Type = Accounting-On > *** Received from 193.63.63.103 port 1814 > Code: Accounting-Request > Identifier: 217 > Authentic: <6><7><204><18><175><169>.<176><146>$<30><168><221><255>l<143> > Attributes: > Acct-Status-Type = Accounting-On > Acct-Authentic = RADIUS > NAS-IP-Address = 193.63.63.103 > NAS-Identifier = "HiveAP3" > Called-Station-Id = "00-19-77-1B-CD-60:eduroam-dev" > Acct-Terminate-Cause = NAS-Reboot > Proxy-State = 0 > > Wed Feb 9 15:21:40 2011: WARNING: Could not find a handler for : request is > ignored > > Thanks for your help, No problem. Please send your config file (no secrets) if you need further comments. Thanks! -- Heikki Vatiainen 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] Log File
On 02/09/2011 07:24 PM, Adam Gerson wrote: > I am trying to troubleshoot a why particular machine can not > authenticate. Is there a log file where I could search by its MAC address? The default log file is /var/log/radius/logfile This comes from LogFile which is by default set to %L/logfile where %L is the LogDir. LogDir is by default set to /var/log/radius What gets logged into log file is controlled by the Trace setting. If you run Radiator with Trace 4 (enables debug logging which *lots* of messages), there is a good chance that you will get enough information about the machine so you can do troubleshooting succesfully. Lower Trace levels, the default is 0, may not produce enough information for debugging purposes. Please also see section "6.0 radiusd" about how to change the Trace level dynamically without the need to do changes in the configuration. Best regards, Heikki -- Heikki Vatiainen 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] 3 Quick Assorted Queries
v-Key,User-Name,Acct- > Status-Type,Acct-Session-ID,Class,Proxy-State,Operator-Name > DupInterval 10 > FramedGroupMaxPortsPerClassC 255 > IgnoreAcctSignature 1 > LivingstonHole 2 > LivingstonOffs 29 > NasType unknown > SNMPCommunity public > > > > AddToReplyIfNotExist Operator-Name=The JNT Association > AllowInReply > User-Name,Reply-Message,State,Class,Message-Authenticator,Calling-Station-I > D,Proxy-State,EAP-Message,MS-MPPE-Send-Key,MS-MPPE-Recv-Key,User-Name,Acct- > Status-Type,Acct-Session-ID,Class,Proxy-State,Operator-Name > DupInterval 10 > FramedGroupMaxPortsPerClassC 255 > IgnoreAcctSignature 1 > LivingstonHole 2 > LivingstonOffs 29 > NasType unknown > SNMPCommunity public > > > > AccountingHandled 1 > AcctLogFileName %L/account.log > AuthByPolicy ContinueUntilReject > RejectHasReason 1 > AuthBy DEV-ADIR-ANY > > > > AccountingHandled 1 > AcctLogFileName %L/account.log > AuthByPolicy ContinueUntilReject > RejectHasReason 1 > AuthBy DEV-ADIR-ANY > > > > AccountingHandled 1 > AcctLogFileName %L/account.log > AuthByPolicy ContinueUntilReject > RejectHasReason 1 > > > > AuditTrail %D/audit.txt > AuthByPolicy ContinueWhileIgnore > BindAddress 0.0.0.0 > DefaultPrivilegeLevel 15 > LogMaxLines 500 > MaxBufferSize 10 > Port 9048 > Protocol tcp > SessionTimeout 3600 > TLS_CAFile %D/certificates/chain > TLS_CertificateFile %D/certificates/orps3.dev.ja.net.crt > TLS_CertificateType PEM > TLS_ExpectedPeerName .+ > TLS_PrivateKeyFile %D/certificates/private.pem > Trace 4 > UseSSL 1 > UseTLS 1 > AuthBy DEV-ADIR-DOMADMIN > > > > Filename %L/statistics > Interval 600 > > > > > On 09/02/2011 16:42, "Heikki Vatiainen" wrote: > >> On 02/09/2011 05:37 PM, Adam Bishop wrote: >> >>> * Can I disable PAP? >> >> You can not stop client sending User-Password attribute, but you can >> create a handler that rejects the request if the attribute is present. >> >> That could direct the users to move e.g. from TTLS/PAP to TTLS/MSCHAPv2 >> or something else that does not cause passwords to be logged with Trace 4. >> >>> * Using fork with AuthByNTLM causes the request to fail: >>> >>> Wed Feb 9 15:22:24 2011: DEBUG: Handling with Radius::AuthNTLM: Wed Feb >>> 9 15:22:24 2011: DEBUG: AuthBy NTLM result: IGNORE, forked >>> >>> Anyone used fork with NTLM? >> >> This does not look like failure to me. This is logged by the parent >> meanwhile the newly forked child is handling the request. The real >> result should come from the child process once it finishes. >> >> You should see messages from the child in the logs while it does NTLM >> authentication. >> >> Why would you need to use fork with NTLM? >> >>> * What do I need to do to get these types of accounting requests >>> handled? The standard user accounting packets are handled fine, but the >>> NAS status updates aren't: >> >> Just guessing here, but if you use Handlers that try to match realms >> there is no User-Name where the realm comes from. >> >> You could try a Handler that has Request-Type = Accounting-Request, >> Acct-Status-Type = Accounting-On >> >>> *** Received from 193.63.63.103 port 1814 >>> Code: Accounting-Request >>> Identifier: 217 >>> Authentic: >>> <6><7><204><18><175><169>.<176><146>$<30><168><221><255>l<143> >>> Attributes: >>> Acct-Status-Type = Accounting-On >>> Acct-Authentic = RADIUS >>> NAS-IP-Address = 193.63.63.103 >>> NAS-Identifier = "HiveAP3" >>> Called-Station-Id = "00-19-77-1B-CD-60:eduroam-dev" >>> Acct-Terminate-Cause = NAS-Reboot >>> Proxy-State = 0 >>> >>> Wed Feb 9 15:21:40 2011: WARNING: Could not find a handler for : >>> request is ignored >>> >>> Thanks for your help, >> >> No problem. Please send your config file (no secrets) if you need >> further comments. >> >> Thanks! >> >> -- >> Heikki Vatiainen >> >> 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. > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] Errors in web-based configuration
On 02/09/2011 10:52 PM, Mike Newton wrote: > Hi there, I'm evaluating Radiator and wanted to point out some errors that > occurred while setting up a configuration through the web interface. > > 1) I pasted a multi-line SQL query into the AcctSQLStatement box, and when > the file was saved it created a separate AcctSQLStatement line for each line > of the SQL query. Needless to say, it didn't work out too well when it came > time to do some accounting. > 2) I manually entered the query into the file, using backslashes to escape > line endings. The web interface loaded and displayed this correctly, but when > I next saved it, the line breaks were stripped out. For long SQL queries, > line breaks and indentation can be very helpful to make sense of what's going > on. > > And a couple of suggestions, again for the web interface. > > 1) It would be nice if the AuthSelect entry in the web interface were a > textbox instead of a plain single-line input. More of those long, complex SQL > queries! > 2) Breadcrumbs would be nice, so I can tell which Handler or AuthBy I'm > looking at, and to give me an easy way back up the config. > 3) For the list of AuthBy sections, it would be much easier to tell them > apart if the Identifier field was shown beside each one. If I have a couple > of AuthBy SQL sections for a handler, I've no way to tell them apart. > > I'm very impressed with the product so far; that the only problems I've had > so far have been with the web interface is a great sign! We're transitioning > from SBR, barring any big surprises in the live testing, and are looking > forward to working with your product. Thanks for your comments and suggestions! We'll take a look at the possible changes for the next release. Please let us know if we can be of further help. Thanks, Heikki -- Heikki Vatiainen 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] RHEL6 install - Can't locate Radius/ServerConfig.pm
On 02/04/2011 09:35 PM, Christian Kratzer wrote:
> On Fri, 4 Feb 2011, Jim Tyrrell wrote:
>> This is a fresh RHEL6 install so should of been a straight perl install
>> and no upgrades. The following RPM's are installed:
>>
>> perl-5.10.1-115.el6.x86_64
>> Radiator-4.7-3.noarch
> Your problem seems to be that the rpm uses diffrent paths from your perl
> installation. Perhaps because you have a 64bit system and the rpm is built
> for a 32 bit perl installation.
I think this is a path problem. Thanks for reporting and diagnosing the
problem.
>> The perl paths are:
>> # perl -e 'print join("\n",@INC);'
>> /usr/local/lib64/perl5
>> /usr/local/share/perl5
>> /usr/lib64/perl5/vendor_perl
>> /usr/share/perl5/vendor_perl
>> /usr/lib64/perl5
>> /usr/share/perl5
>>
>> The missing file is located:
>> /usr/lib/perl5/site_perl/5.10.0/Radius/ServerConfig.pm
The problem seen here is that the LSB seems not to cover Perl paths. The
RPM is built to support LSB but specifics of Perl libraries seem to
change from one installation to another. LSB is Linux Standard Base
which aims to specify file system layout, libraries and other such things.
We have already discussed about options but do not have new RPMs yet.
> I would suggest that you remove the rpm and install from the tarball.
> The Makefile will automatically find the best path to match your setup.
This is my suggestion too for now on until the RPM path issues have been
resolved.
One thing that may help with tarball is the small change to radiusd that
is in 4.7 patches. radiusd now supports -I option which can be used to
specify one include path for finding Perl modules. The idea is to have
better support for setups where Radiator is run from where the tarball
was unpacked.
You can now do this:
radiusd -I /opt/local/whatever/Radiator-4.7 ...
instead of
perl -I /opt/local/whatever/Radiator-4.7 radiusd ...
This can be useful with /etc/init.d/ scripts where the module path can
now be specified as a part of radiusd arguments.
--
Heikki Vatiainen
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] check-items in chained authby queries
On 02/04/2011 06:29 AM, Michael wrote: > > oh, and, you may not want to stop there. you may want to find out why %0 and > %1 > don't work. I think it should as per source code and manual. Since you are > using the 2 '?' the order is very important. You can't change the order of: > > WHERE username=? AND groupname=? > > to this: > WHERE groupname=? AND username=? > > ..cause it will not work and will break your setup. > > Maybe the radiator coders can check out the source. i'm sure they'll see > these > emails. To me, the source looks fine. Michael, Linuxchuck, thanks for letting us know about the problems with GroupMembershipQuery. If the database driver complains about bind errors, Michael's example and the notes about the order of arguments is what can be followed to solve the problem. Radiator currently always supplies username and groupname as 'bind variables' that are used as arguments for placeholders '?' in GroupMembershipQuery statement. If the statement does not have placeholders '?', some database drivers accept the query and ignore the bind variables while others complain about missing placeholders. We have discussed about ways to clarify how GroupMembershipQuery works, but making changes to code could easily break backwards compatibility with existing configurations so we want to be careful with that. No patches have been made yet, but please check the change history when you upgrade the next time. Thanks, Heikki -- Heikki Vatiainen 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] PEAP Unknow Problem
n\<8><170><8><232>v > Attributes: > EAP-Message = > <1><13><0>&<25><0><23><3><1><0><27><142><161>LC<17>Mf<13>z<223>s'f<169>m<243><31>p<3><176><238>%<228><1><13>E<214> > Message-Authenticator = > <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > > Wed Feb 16 18:20:17 2011: DEBUG: Packet dump: > *** Received from port 32768 > Code: Access-Request > Identifier: 133 > Authentic: <&,<153><12>#J<149><224><205>m<195><157>O]<255> > Attributes: > User-Name = "mikem" > Calling-Station-Id = "" > Called-Station-Id = ":Prueba" > NAS-Port = 13 > NAS-IP-Address = > NAS-Identifier = "" > Airespace-WLAN-Id = 4 > Service-Type = Framed-User > Framed-MTU = 1300 > NAS-Port-Type = Wireless-IEEE-802-11 > Tunnel-Type = 0:VLAN > Tunnel-Medium-Type = 0:802 > Tunnel-Private-Group-ID = 509 > EAP-Message = > <2><13><0>&<25><0><23><3><1><0><27>$<146><203>O<132><10><166><202>5<12>=<173><31><155><17><213><27><205><235><242>m<156><2>sU9: > Message-Authenticator = > :<19>e<28><248><178><134><127><225><13><192><236>m<149><8><241> > > Wed Feb 16 18:20:17 2011: DEBUG: Handling request with Handler > 'NAS-IP-Address=""', Identifier 'EAP-PEAP' > Wed Feb 16 18:20:17 2011: DEBUG: Deleting session for mikem, , 13 > Wed Feb 16 18:20:17 2011: DEBUG: Handling with Radius::AuthFILE: > Wed Feb 16 18:20:17 2011: DEBUG: Handling with EAP: code 2, 13, 38, 25 > Wed Feb 16 18:20:17 2011: DEBUG: Response type 25 > Wed Feb 16 18:20:17 2011: DEBUG: EAP result: 1, PEAP Authentication Failure > Wed Feb 16 18:20:17 2011: DEBUG: AuthBy FILE result: REJECT, PEAP > Authentication Failure > Wed Feb 16 18:20:17 2011: INFO: Access rejected for mikem: PEAP > Authentication Failure > Wed Feb 16 18:20:17 2011: DEBUG: Packet dump: > *** Sending to port 32768 > Code: Access-Reject > Identifier: 133 > Authentic: <139><15>:<199><235><158>(<143><131><134><189><152> 6L<217> > Attributes: > EAP-Message = <4><13><0><4> > Message-Authenticator = > <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > Reply-Message = "Request Denied" > > > > ## > > ## > > > De: Christian Kratzer [c...@cksoft.de] > Enviado el: miércoles, 16 de febrero de 2011 16:36 > Para: Raúl Tejeda Calero > CC: radiator@open.com.au > Asunto: Re: [RADIATOR] PEAP Unknow Problem > > Hi, > > On Wed, 16 Feb 2011, Raúl Tejeda Calero wrote: > >> Hi, >> >> I´m still having problems with my PEAP-MSCHAP-V2 configuration. >> >> But the problem seems more complex this time and I don´t sure to understand >> the process. >> >> The log shows this: >> >> Schema: >> 1) EAPChallenge for mikem >> 2) Access challenged for anonymous: EAP PEAP Challenge >> 3) Access challenged for mikem: EAP PEAP inner authentication redispatched >> to a Handler >> 4) EAP PEAP inner authentication request for anonymous >> 5) Access challenged for anonymous: EAP MSCHAP-V2 Challenge >> 6) Access challenged for mikem: EAP PEAP inner authentication redispatched >> to a Handler >> 7) Radius::AuthFILE looks for match with mikem [anonymous] >>Radius::AuthFILE ACCEPT: : mikem [anonymous] >>EAP result: 1, EAP MSCHAP-V2 Authentication failure >> >> Thanks for the help. >> Raúl Tejeda >> >> ** Details: ** >> >> Radius.cfg: >> ## >> ## >> >> # Basic radius configuration # >> >> # outer auth with just PEAP >> >> >> EAPType PEAP, MSCHAP-V2 >> Filename %D/users-eap >>EAPTLS_CAFile %D/certificados/CAxxx.pem >>EAPTLS_CAPath %D/certificados >>EAPTLS_CertificateFile %D/certificados/serverxxx.pem >>EAPTLS_CertificateType PEM >>EAPTLS_PrivateKeyFile %D/certificados/serverxxx.key >>EAPTLS_MaxFragmentSize 500 >> >> >> >> # inner auth with MS-CHAP-V2 >> >> >> RewriteUsername s/(.*)\\(.*)/$2/ >> EAPType MSCHAP-V2 >> Filename %D/users >>EAPTLS_CAFile %D/certificados/CAxxx.pem >>EAPTLS_CertificateFile %D/certificados/serverxxx.pem >>EAPTLS_CertificateType PEM >>EAPTLS_PrivateKeyFile %D/certificados/serverxxx.key >>EAPTLS_MaxFragmentSize 500 >> >> > > you might want to do the following: > > 1. Swap the order of the two handlers so that the more specific > TunneledByPEAP handler > is checked first. From looking at your logs it seems all requests go > into your outer auth handler and thus into the wrong AuthBy FILE. > > 2. Drop the MSCHAP-V2 from your EAPType list in your outer auth handler. > It is of no use there as there is no MSCHAP in the outer authentication. > > 3. Drop all the EAPTLS options from your inner auth as they are no use for > MSCHAP. > > 4. Add identifiers to both handlers so you can more easily identify them in > your logs. > Something like this for the outer handler > > Identifier EAP-PEAP > > and this for the inner > > Identifier EAP-MSCHAP-V2 > > This should get you a bit further. If it still does not work post the > new config and the appropriate log and we should see what is happening. > > Greetings > Christian Kratzer > CK Software GmbH > > -- > Christian Kratzer CK Software GmbH > Email: c...@cksoft.de Wildberger Weg 24/2 > Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden > Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart > Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] Thawte Intermediate certificates
On 02/16/2011 07:01 PM, Carl Gibbons wrote: > I was given a file named SSL_CA_Bundle.pem containing intermediate > certificates necessary for our new Radiator SSL cert from Thawte. > What to do with these? Our installation is on RHEL5. > > I tried putting them in the .pem file specified by the > EAPTLS_CertificateFile directive keyword in our config, but that > didn't work. A colleague suggested they may need to go in > /etc/pki/tls/certs/ca-bundle.crt, but I don't have the extra > information about the intermediate certs that I see in that file. Do this: EAPTLS_CAFile /path/to/certs/SSL_CA_Bundle.pem EAPTLS_CertificateType PEM EAPTLS_CertificateFile /path/to/certs/server-cert.pem EAPTLS_PrivateKeyFile /path/to/certs/server-key.pem # If the key is password protected # EAPTLS_PrivateKeyPassword key-password The path "/path/to/certs" can be anything. Some people use /etc/radiator, /etc/radius or /etc/radiator/certs. In many cases it is the same directory where Radiator configuration lies. You mention "Radiator SSL cert from Thawte". This is what goes into EAPTLS_CertificateFile and the cert's private key goes to EAPTLS_PrivateKeyFile. The bundle goes into EAPTLS_CAFile. This should enable Radiator to send the clients its own cert and all required CA certificates. The bundle can also contain the root CA, but the intermediates should be enough. Best regards, Heikki -- Heikki Vatiainen 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] UserName Rewrite Function
On 02/17/2011 02:44 AM, Rianto Wahyudi wrote: > We have MySQL database containing email alias which map into Active Directory > user. > Ie : rianto.wahy...@latrobe.edu.au mapped to rwahy...@ltu.edu.au > > > I would like to utilize this database so user can login with their email > address or their AD username. > Is it possible to pass UserNameRewrite to a function or another perl script ? RewriteUserName expects its argument to be something that Perl binding operator can use: http://perldoc.perl.org/perlop.html#Binding-Operators For me it looks like you can not use a function to map the email addresses to AD usernames. > All authentication are done via NTLM, and I believe radiator use ntlm_auth > program. > Is it possible to create a wrapper for ntlm_auth script ? This is an interesting idea. Ntlm_auth is launced with open2() function http://perldoc.perl.org/IPC/Open2.html Parameters are written with print() to $chld_out and read with readline() from $child_in. A single dot signals the end of input or output as documented by ntlm_auth man page. So the communcation is quite simple and if you decide to give this a try, it would be interesting to hear about the results. > Here is my handler setup : > > # STUDENTS DOMAIN TTLS > TunnelledByTTLS=1,Realm=/students.*/i> > RewriteUsername s/^\@.*// > > EAPType MSCHAP-V2 > Domain STUDENTS > UsernameMatchesWithoutRealm > > -- Heikki Vatiainen 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] eap peap + ntlm_auth
On 02/17/2011 05:56 AM, James wrote:
> I'm attempting to get EAP MSCHAPv2 (EAP PEAP) to work with wireless so
> that our Cisco Wireless LAN Controllers can bounce user authentication
> off of Radiator.
>
> My understanding is that I should be using the
> goodies/ntlm_eap_peap.cfg configuration file to start building off of.
>
> This file indicates that there are a few moving parts that need to be
> put in place for this to work properly:
>
> (a) smb.conf file must be fleshed out
> (b) ntlm_auth must function for EAP PEAP to work
>
> Correct?
Yes, if your user database is AD.
You could use e.g., plain LDAP if you have access to {nthash}passwords
or plain text passwords. So PEAP does not necessarily imply AD.
> I'm currently stuck at ntlm_auth not functioning at all. Take this
> output as an example:
>
> # ntlm_auth --username=testuser --domain= --password='blah'
> could not obtain winbind separator!
> Reading winbind reply failed! (0x01)
> : (0x0)
>
> A quick tcpdump shows that this command DOES NOT in any way generate
> any network traffic. Doh.
>
> I guess part of my confusion is whether or not I must "net join" my
> system to the domain. Is that a requirement?
Yes. You must have winbind running, no need for smbd or nmbd, and you
must do "net ads join ..." once.
> My smb.conf file look as follows:
>
> [global]
># Replace 'OPEN' with the name of your Windows domain:
>workgroup = MYDOMAIN
>security = domain
>password server = *
>
> This is pretty much a one-line change from the smb.conf file found in
> the goodies directory.
>
> Any ideas on why this is failing?
Probably missing domain join is the main thing.
Also see this:
http://www.open.com.au/pipermail/radiator/2010-February/016091.html
Please let us know of your results. The settings seem to always differ
more or less between different environments.
--
Heikki Vatiainen
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] UserName Rewrite Function
On 02/17/2011 11:59 PM, Rianto Wahyudi wrote: > We are currently still on evaluation stage, and having the trial version > installed. I can not see the source code of the radiator but I'm interested > to do some hacking. > > Just few more questions : > - How does radiator know the location of ntlm_auth? Is it using standard > linux path ? > - Is it possible to specify ntlm_auth location so it doesn't use the standard > one ? See http://www.open.com.au/radiator/documentation.html and ref.pdf there To quote section "5.65.3 NtlmAuthProg" This optional parameter specifies the path name and arguments for the ntlm_auth program. Defaults to ‘/usr/bin/ntlm_auth --helper-protocol=ntlm-server-1’. This allows you to run what ever you want as NtlmAuthProg. -- Heikki Vatiainen 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] UserName Rewrite Function
On 02/21/2011 01:30 AM, Rianto Wahyudi wrote:
> I think I manage to create a simple wrapper for ntlm_auth. Please see below
> for the code.
> One problem with the script is that I don't know how to exit properly.
>
> If I don't use exit $auth, the authentication process seems to stall.
> If I use exit $auth, authentication process works but it creates zombie
> process.
>
> root 20430 0.0 1.2 19368 13224 ?Ss 10:03 0:00
> /usr/bin/perl /usr/bin/radiusd -config_file /etc/radiator/radius.cfg -daemon
> root 20528 0.0 0.0 0 0 ?Z10:06 0:00 \_
> [ltu_ntlm_auth]
>
> Could you please let me know proper way to exit ? What value radiator expect
> from running ntlm_auth?
Try not to exit. Keep your ntlm_auth wrapper running. This is how
ntlm_auth behaves when it is called directly by Radiator. If it exists,
then your wrapper should restart it. This is good for performance
In case ntlm_auth exits, you should make arrangements to catch SIGCHLD
to prevent zome processes.
See http://perldoc.perl.org/perlipc.html and search for CHLD. I have not
done this type of programming for a long while, but I suspect the zombie
results from your script not being able to exit since it has not
wait()ed or otherwise handled the termination of ntlm_auth it calls.
If the authentication still seems to stall, you should check how to
flush the socket so that the output from your script does not get
buffered but is delivered completely to Radiator. I'm not completely
sure, but stalling sounds like a buffer related problem.
> #!/usr/bin/perl
>
> use FileHandle;
> use IPC::Open2;
> use MIME::Base64;
> use strict;
> my @input = @ARGV;
> my $auth;
> my $line;
> my $username;
>
>
> my $pid = open2(*NTLM_OUT, *NTLM_IN, "/usr/bin/ntlm_auth @input");
> while () {
> $line = $_;
> if ( $line =~ /^Username/)
> {
> #rewrite username here
> $username = $line;
> $username =~ s/Username\:\: //g;
> $line = usermap (decode_base64($username));
> }
> print NTLM_IN $line;
> if ($line =~ /^\.$/)
> {
> while () {
> print $_;
> last if $_ =~ /^\.$/;
> if ($_ =~ /Authenticated: No/) {
> $auth = 1;
> }
> if ($_ =~ /Authenticated: Yes/ ){
> $auth = 0;
> }
> }
> exit $auth;
> }
>
> }
>
> sub usermap
> {
> my $uname = $_[0];
> if ( $uname =~ /r\.wahyudi/ )
> {
> $uname="rwahyudi";
> }
> $uname = "Username:: ".encode_base64($uname);
> return "$uname";
> }
> exit $auth;
>
--
Heikki Vatiainen
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] PEAP Anonymous Hook
On 02/22/2011 04:57 PM, Raúl Tejeda Calero wrote: > I finally fixed the problem, as Mikem show in the eap_anon_hook, my client > send an "[anonymous] " when i try to handle PEAP. Sorry, did not fully understand the above, but about the log message: Tue Feb 22 12:23:19 2011: DEBUG: Radius::AuthFILE looks for match with mikem [anonymous] Here "mikem" is the actual username that is used for looking up user information. "[anonymous]" is the original username from the request. In other words, "mikem" is what should be in the AuthBy FILE file. > I want to use the eap_anon_hook, but i don´t understand how it works. That is used to match authentication messages to their related accounting messages. With PEAP, for example, the WLAN AP or controller sees only the outer identity, such as @example.com. The real identity, for example h...@example.com, is part of MSCHAPv2 and is known only by the client and the RADIUS server. This hook modifies the accounting requests WLAN AP or controller sends and changes User-Name @example.com to h...@example.com. So it does not help with your authentication problem. > ¿Where´s the location of the hook? ¿it works with Active Directory? The hook is in goodies/ directory. You can use it with any AuthBy > Thanks in advance! > > Raúl Tejeda > > De: radiator-boun...@open.com.au [radiator-boun...@open.com.au] En nombre de > Raúl Tejeda Calero [raul.tej...@satec.es] > Enviado el: martes, 22 de febrero de 2011 11:45 > Para: Heikki Vatiainen > CC: radiator@open.com.au > Asunto: Re: [RADIATOR] PEAP Unknow Problem > > Hello, i´m here again. > >> It looks better, but don´t work. Now, the challenge pass-through to the >> MSCHAP-V2 Handler, but it shows the same error message: > >> Christian already took care of most issues, I'll try to continue. > >> You are currently using RewriteUsername. That may cause problems if >> Radiator and the client calculate MSCHAPv2 challenges and responses >> using different (original and rewritten) usernames. > >> However, it looks like you are using mikem as the username and it does >> not get changed. Or is mikem exactly what you use with your client? You >> may try commenting out RewriteUsername while you do testing. > > I have tried it. Using rewrite username with $1 (mikem), $2 (anonymous) and > without "rewriteusername". And the result was the same. > >> About your clients file. If you really had this: >> mikem user-password = x >> you would get an error since user-name is not written as User-Password. >> The error would be something like this: "Check item user-password >> expression 'password' does not match '' in request" for a line like this >> in the users file: >> mikem user-password = "password" > > Sorry, it was a writing-mistake. My user file is correct and works with AAA. > > Any troubleshooting idea? > > Regards and thanks in advance, > Raúl Tejeda > > New Radius.cfg: >> >> ## >> >> ## >> >> #basic configuration >> # inner auth with MS-CHAP-V2 >> >> Identifier EAP-MSCHAP-V2 >> >> EAPType MSCHAP-V2 >> Filename %D/users >> >> >> >> # outer auth with just PEAP >> >> Identifier EAP-PEAP >> >> EAPType PEAP >> Filename %D/users-eap >> EAPTLS_CAFile %D/certificados/CA.pem >> EAPTLS_CAPath %D/certificados >> EAPTLS_CertificateFile %D/certificados/Serv.pem >> EAPTLS_CertificateType PEM >> EAPTLS_PrivateKeyFile %D/certificados/Serv.key >> EAPTLS_MaxFragmentSize 1000 >> >> >> > > > New logfile: > ## > > ## > Tue Feb 22 12:23:03 2011: NOTICE: SIGTERM received: stopping > Tue Feb 22 12:23:04 2011: DEBUG: Finished reading configuration file > '/etc/radiator/radius.cfg' > Tue Feb 22 12:23:04 2011: DEBUG: Reading dictionary file > '/etc/radiator/dictionary' > Tue Feb 22 12:23:04 2011: DEBUG: Creating authentication port :1812 > Tue Feb 22 12:2
Re: [RADIATOR] PEAP Unknow Problem
t;230><144><241><7>|@<227>X<193>?<17><222>Z<183><20><11>}m<160><236><181>OX<132><148>-<226><201><25>G<27><18><25><216>s<222>`_<203><154><14><227>[[<<166><180>q<135><162><154><211>wF<21><217><157>M<17><157><136><131>=<209><142><10><161><188><216><157><153>jo<201>
> Message-Authenticator =
> L<19>b<233><240><218><211>k<155><135><167>aww<23><226>
>
> Tue Feb 22 12:23:19 2011: DEBUG: Handling request with Handler
> 'NAS-IP-Address=""', Identifier 'EAP-PEAP'
> Tue Feb 22 12:23:19 2011: DEBUG: Deleting session for mikem, , 13
> Tue Feb 22 12:23:19 2011: DEBUG: Handling with Radius::AuthFILE:
> Tue Feb 22 12:23:19 2011: DEBUG: Handling with EAP: code 2, 12, 87, 25
> Tue Feb 22 12:23:19 2011: DEBUG: Response type 25
> Tue Feb 22 12:23:19 2011: DEBUG: EAP PEAP inner authentication request for
> anonymous
> Tue Feb 22 12:23:19 2011: DEBUG: PEAP Tunnelled request Packet dump:
> Code: Access-Request
> Identifier: UNDEF
> Authentic: <26>Y<152><144><228><185>S'3w<207><248><200><4><170>^
> Attributes:
> EAP-Message =
> <2><12><0><<26><2><12><0>;1<177><183>Jv<24>KJ<169>I<169><31><140><251>,.<214><0><0><0><0><0><0><0><0>I<175>d<206><166><160>Gn-<233>Q<12>{<5><186><12><178><166><217><189><232><28><176>h<0>mikem
> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> NAS-IP-Address =
> NAS-Identifier = ""
> NAS-Port = 13
> Calling-Station-Id = ""
> User-Name = "anonymous"
>
> Tue Feb 22 12:23:19 2011: DEBUG: Handling request with Handler
> 'NAS-IP-Address="",TunnelledByPEAP=1', Identifier 'EAP-MSCHAP-V2'
> Tue Feb 22 12:23:19 2011: DEBUG: Deleting session for anonymous, , 13
> Tue Feb 22 12:23:19 2011: DEBUG: Handling with Radius::AuthFILE:
> Tue Feb 22 12:23:19 2011: DEBUG: Handling with EAP: code 2, 12, 60, 26
> Tue Feb 22 12:23:19 2011: DEBUG: Response type 26
> Tue Feb 22 12:23:19 2011: DEBUG: Reading users file /etc/radiator/users
> Tue Feb 22 12:23:19 2011: DEBUG: Radius::AuthFILE looks for match with mikem
> [anonymous]
> Tue Feb 22 12:23:19 2011: DEBUG: Radius::AuthFILE ACCEPT: : mikem [anonymous]
> Tue Feb 22 12:23:19 2011: DEBUG: EAP result: 1, EAP MSCHAP-V2 Authentication
> failure
> Tue Feb 22 12:23:19 2011: DEBUG: AuthBy FILE result: REJECT, EAP MSCHAP-V2
> Authentication failure
> Tue Feb 22 12:23:19 2011: INFO: Access rejected for anonymous: EAP MSCHAP-V2
> Authentication failure
> Tue Feb 22 12:23:19 2011: DEBUG: Returned PEAP tunnelled packet dump:
> Code: Access-Reject
> Identifier: UNDEF
> Authentic: <26>Y<152><144><228><185>S'3w<207><248><200><4><170>^
> Attributes:
> EAP-Message = <4><12><0><4>
> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
> Reply-Message = "Request Denied"
>
> Tue Feb 22 12:23:19 2011: DEBUG: EAP result: 3, EAP PEAP inner authentication
> redispatched to a Handler
> Tue Feb 22 12:23:19 2011: DEBUG: AuthBy FILE result: CHALLENGE, EAP PEAP
> inner authentication redispatched to a Handler
> Tue Feb 22 12:23:19 2011: DEBUG: Access challenged for mikem: EAP PEAP inner
> authentication redispatched to a Handler
> Tue Feb 22 12:23:19 2011: DEBUG: Packet dump:
> *** Sending to port 32768
> Code: Access-Challenge
> Identifier: 216
> Authentic: <20><212><236><140>G<192>iVF<225><234><248><165><239><128><171>
> Attributes:
> EAP-Message =
> <1><13><0>&<25><0><23><3><1><0><27>w<235><158><132><202><146><217><246><174><196><159><127><135><233><217>r<211><153><190><150>Hq&
Re: [RADIATOR] Tacacs role reply.
On 02/24/2011 10:09 PM, Mark Bassett wrote: > Hi guys, I’m using tacacs+ on some cisco SanOS fiber switches. I am > able to authenticate and log in properly, but I am not being assigned > the proper tacacs role > > “network-admin” > I need to add this pair > > cisco-av-pair=shell:roles="network-admin" > but I am not sure where to add it. If you want to add it per use, you should arrange the avpair to be returned during the authentication. For example, if I authenticated against a file, the file could contain this: hvn User-Password = "password" tacacsgroup = group1 cisco-avpair = shell:roles="network-admin" The reference manual and goodies/tacacsplusserver.cfg, say this: Any cisco-avpair reply items that result from the Radius authentication will be used for TACACS+ authorization. Just noticed you posted your configuration. If you can arrange your LDAP server to return an attribute that contains the avpair value, you can do this within AuthBy LDAP2: AuthAttrDef ciscoAvPair,cisco-avpair,reply where ciscoAvPair is the LDAP attribute that contains the desired avpair value. An alternative and possibly a way to test the above is to add this into your : AuthorizationAdd shell:roles="network-admin" The above will add the avpair to all authorization requests. That's why you may want to consider if it is ok to allow the attribute for all tacacs users. Please see doc/ref.pdf section 5.86 and goodies/tacacsplusserver.cfg for more information. Thanks, Heikki -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Memory leak with Perl Script to get via SNMP the client IP from Cisco AP 1100
On 02/24/2011 11:00 AM, Gerard Alcorlo Bofill wrote: > sorry for resending the same question. But I sent this question at the > end of another mail with a not related subject, (Re: [RADIATOR] > Assigning IP's directly from the Radius server), and maybe that's de > reason because no one could help me. Or maybe we got scared of threads :) > I'm using a home made PostProcessingHook. But it's suffering a memory > leak. Could someone take a look at my script? I'm not an expert on perl > and I'm using a thread to do non active waiting... I would try replacing the thread with add_timeout function. Then you do not have to use threads and can use the same timing support that rest of Radiator uses. grep for add_timeout in Radius/ directory for examples. The function lives in Select.pm. > What's wrong on this script? Hard to say. If you can replace threads with add_timeout, then we could at least know if the leak is a side effect from using threads or not. I really do not know how Perl's memory management works with threads. Thanks! -- Heikki Vatiainen, Arch Red Oy +358 44 087 6547 ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Memory leak with Perl Script to get via SNMP the client IP from Cisco AP 1100
On 02/25/2011 03:32 PM, Gerard Alcorlo Bofill wrote:
> the error I'm receiving by mail is:
>
>
> Your program
>
>/usr/local/bin/radiusd -config_file
> /etc/radiator/radiuscesca/radiuscesca.cfg -foreground
>
> exited unexpectedly with exit status 25,
> signal number 0 and dump indication 0.
>
> The STDERR output was Not a HASH reference at (eval 135) line 28.
> .
>
> The program will be restarted again by /sbin/restartWrapper in 2 seconds.
>
> I'm sure it's a good tip.
It is. I'd say the fix is not to try to remove the timeout. So remove
this line:
&Radius::Select::remove_timeout($mimateix->{moment});
The timeout runs only once and they should only be removed when they
have not run yet and for some reason it is not desired that the timeout
callback runs at all.
> Thanks!
>
> Al 25/02/11 14:23, En/na Gerard Alcorlo Bofill ha escrit:
>> Hello,
>>
>> thanks Christian and Heikki for your advise.
>>
>> I've done some short code with the timeout but every time this code is
>> executed Radiator restarts.
>>
>> I'm trying to remove the timeout at the end of the "important things".
>>
>> Do you know why when I execute this Radiator exits?
>>
>>
>> sub {
>>
>> &main::log($main::LOG_DEBUG, "||| wait 5 segons |||" . time);
>>
>> my $referencia={};
>> $referencia->{moment} = &Radius::Select::add_timeout(time + 5,
>>sub {
>> my ($mimateix) = @_;
>>
>> &main::log($main::LOG_DEBUG, "== do important things ==");
>>
>> &Radius::Select::remove_timeout($mimateix->{moment});
>> &main::log($main::LOG_DEBUG, time. ">>> Finished <<<");
>>}
>> , $referencia);
>> }
--
Heikki Vatiainen
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] Colubris-AVPair
On 02/28/2011 06:31 AM, Jeffrey Lee wrote: > Mon Feb 28 15:27:01 2011: ERR: Attribute number 254 (vendor 8744) is not > defined > in your dictionary > Mon Feb 28 15:27:01 2011: ERR: Attribute number 251 (vendor 8744) is not > defined > in your dictionary > Mon Feb 28 15:27:01 2011: ERR: Attribute number 253 (vendor 8744) is not > defined > in your dictionary > Mon Feb 28 15:27:01 2011: ERR: Attribute number 252 (vendor 8744) is not > defined > in your dictionary > > > i've checked the dictionary file (which is read by radiusd when it > started). the vendor (colubris) and vendor attribute (colubris-avpair) > seems to be defined. Yes, Colubris attribute number 0 is defined, but attributes 251 - 254 are not defined since their names and types are not known. Would you have documentation for those attributes so they could be added to the dictionary? > # > # Colubris Networks CN3000 > # Values for Colubris-AVPAIR are in the form name=value > # for example > # smtp-redirect=192.168.10.102 > # > VENDOR Colubris 8744 > VENDORATTR8744 Colubris-AVPAIR 0 string About the "No such attribute" message, the attribute name is case sensitive. Change your configuration to this: AddToReply Colubris-AVPAIR="access-list=main..." The attribute should then be sent to the Colubris AP. Thanks! Heikki > On Mon, Feb 28, 2011 at 2:34 PM, Jeffrey Lee wrote: >> Hi, >> >> I've configured the return-list attribute to include something like >> >> >> AddToReply >> Colubris-AVPair="access-list=main,ACCEPT,all,192.168.1.1,all",\ >> ... >> >> When I started radiusd and attempted to authenticate a Colubris AP, I >> get this warning message... >> >> >> WARNING: No such attribute Colubris-AVPair >> >> >> Can you let me know how do I add this to the dictionary so that this >> warning does not appear? >> >> >> thanks, >> Jeff >> > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] Problem Radiator configuration WIMAX
><11>&Q=<147>y<221><209><143>_<21 > 2><238>fH<19><213> > EAP-Message = <253><30><212><243>Qw<224>A<127>,<162><213>`8l > <164><246>g<180>\D<222><17><196>n<7>t<189><201><4>m<140><240>w<138><218> > -F<223>c<234>s<175>~w<176><136><229>wm<214><29><5><236><142><226><212><0 >> N`<209>0<14><150><232><134><152>I0)<166>F<145>I<156> > <181><212>c<142>F<26><214>6<231><15>F#zz8<16>R<136><149><133><229><25>3~ > <250>gx<25>,<157>&<158>N<188><229>0(<225>7<15><195>/<242><127><178>vQ<13 > 9><231>"<26>yz<171><10><136><164><214>\<208><144><17><6>1<0><181><13><1> > Ri<12><166>D<130><164>F<2><177>*^<208><5><193><239>e<2><3><1><0><1><163> > <130><1><1>0<129><254>0<29><6><3>U<29><14><4><22><4><20>V}<185>_<26><239 >> <29>:Uv<148><211><193><179><240>,M<<12><253>0<129><206><6><3>U<29>#<4>< > 129><198>0<129><195><128><20>V}<185>_<26><239><29>:Uv<148><211><193><179 >> <240>,M<<12><253><161><129><159><164><129><156>0<129><153>1<11>0 > EAP-Message = > <9><6><3>U<4><6><19><2>EC1<14>0<12><6><3>U<4><8><19><5>Azuay1<15>0<13><6 >> <3>U<4><7><19><6>Cuenca1<16>0<14><6><3>U<4><10><19><7>ETAPAEP1<23>0<21> > <6><3>U<4><11><19><14>Comunicaciones1<27>0<25><6><3>U<4><3><19><18>wimax > .etapanet.net1!0<31><6><9>*<134>H<134><247><13><1><9><1><22><18>wimax@et > apanet.net<130><9><0><253><9><210><254><134><251><218><188>0<12><6><3>U< > 29><19><4><5>0<3><1><1><255>0<13><6><9>*<134>H<134><247><13><1><1><5><5> > <0><3><130><1><1><0>l<198><217>_<9>t<250>oL]<200><25>rN<252><242>Lt<2><2 > 10><236><142><176><168>a<155><19><191><255><146><246><169>y<8><247>in<25 > 2><157><27><151>f<244><134>4<207><191><171><7>F<243><179><15>,)<237><205 >> P > EAP-Message = > <15><26><243><11><212>n<25>~<154>v<176><237><129><156>B4kIb<128><208>V[< > 241><185><18><154>x<14><228><139>.<157><165> > Message-Authenticator = > <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > > Tue Mar 1 12:18:49 2011: DEBUG: Monitor received command: STATS . > Tue Mar 1 12:18:50 2011: DEBUG: Monitor received command: STATS . > Tue Mar 1 12:18:51 2011: DEBUG: Monitor received command: ID > T
Re: [RADIATOR] Colubris-AVPair
On 03/01/2011 01:10 AM, Jeffrey Lee wrote: > another issue I'm facing with Colubris-AVPair is... > > i'm hardcoding the return-list attributes in the radius.cfg file. the > way HP WLAN controller works is, it may require some placeholders to > be coded and the placeholders that is understood by the HP WLAN > controller uses special characters like %, e.g., %E, %m... but > somehow, when I run radiator, these special characters get translated > by radiator on runtime. how do I code them to avoid radiator > processing these special characters? The reference manual doc/ref.pdf section "5.18.8 AddToReply" says that the attribute values are subject to special character expansion. > below is how I've coded in radius.cfg file.. > > AddToReply > Colubris-AVPAIR="login-url=https://192.168.10.100/login.asp?cip=%c&ssid=%E&mac=%m&loginurl=%l",\ > > Colubris-AVPAIR="welcome-url=https://192.168.10.100/welcome.asp?oriurl=%o"; To get a % sign, you should use %%. For example, cip=%%c Best regards, Heikki -- Heikki Vatiainen 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] RV: Problem Radiator configuration WIMAX
lt;152> > MS-CHAP2-Response = > U<0>!@#$%^&*()_+:3|~<0><0><0><0><0><0><0><0>-<17><2><129><24>*<217><224>V<1><158><209><169><192>&&<20><227><13><10><189><143><215><174> > > Wed Mar 2 16:05:20 2011: DEBUG: EAP TTLS inner authentication request for > wimax > Wed Mar 2 16:05:20 2011: DEBUG: Handling request with Handler > 'Realm=DEFAULT', Identifier '' > Wed Mar 2 16:05:20 2011: DEBUG: Deleting session for wimax, 3.3.3.3, > Wed Mar 2 16:05:20 2011: DEBUG: Handling with Radius::AuthSQL: > Wed Mar 2 16:05:20 2011: DEBUG: Handling with Radius::AuthSQL: > Wed Mar 2 16:05:20 2011: DEBUG: Query is: 'select reason from blacklist > where nai=NULL': > Wed Mar 2 16:05:20 2011: DEBUG: Radius::AuthSQL looks for match with [wimax] > Wed Mar 2 16:05:20 2011: DEBUG: Radius::AuthSQL REJECT: No such user: > [wimax] > Wed Mar 2 16:05:20 2011: DEBUG: Query is: 'select reason from blacklist > where nai='DEFAULT'': > Wed Mar 2 16:05:20 2011: DEBUG: AuthBy SQL result: ACCEPT, No such user > Wed Mar 2 16:05:20 2011: DEBUG: Handling with Radius::AuthWIMAX: AAA-WIMAX > Wed Mar 2 16:05:20 2011: DEBUG: Handling with Radius::AuthWIMAX: AAA-WIMAX > Wed Mar 2 16:05:20 2011: DEBUG: Query is: 'select psk, cui, hotlineprofile > from subscription where nai=?': wimax > Wed Mar 2 16:05:20 2011: DEBUG: Query is: 'select profileid, > httpredirectionrule, ipredirectionrule, nasfilterrule, sessiontimer from > hotlineprofile where id=?': 0 > Wed Mar 2 16:05:20 2011: DEBUG: Radius::AuthWIMAX looks for match with wimax > [wimax] > Wed Mar 2 16:05:20 2011: ERR: Could not handle an EAP request: Undefined > subroutine &Radius::MSCHAP::ASCIItoUnicode called at > /usr/lib/perl5/site_perl/Radius/AuthGeneric.pm line 866. > > Wed Mar 2 16:05:20 2011: DEBUG: AuthBy WIMAX result: REJECT, Could not > handle an EAP request > Wed Mar 2 16:05:20 2011: INFO: Access rejected for 00256831312f: Could not > handle an EAP request > Wed Mar 2 16:05:20 2011: DEBUG: Packet dump: > *** Sending to 3.3.3.3 port 10033 > > Packet length = 36 > 03 1b 00 24 60 fc ea e7 98 51 59 ae 23 eb dc a9 > ca 25 a7 1f 12 10 52 65 71 75 65 73 74 20 44 65 > 6e 69 65 64 > Code: Access-Reject > Identifier: 27 > Authentic: `<252><234><231><152>QY<174>#<235><220><169><202>%<167><31> > Attributes: > Reply-Message = "Request Denied" > > Wed Mar 2 16:05:20 2011: DEBUG: Monitor received command: STATS . > Wed Mar 2 16:05:21 2011: DEBUG: Monitor received command: STATS . > Wed Mar 2 16:05:22 2011: DEBUG: Monitor received command: STATS . > Wed Mar 2 16:05:23 2011: DEBUG: Monitor received command: STATS . > > > Saludos, > > Augusto Cabrera Duffaut. > > > > > -Mensaje original- > De: Heikki Vatiainen [mailto:h...@open.com.au] > Enviado el: miércoles, 02 de marzo de 2011 16:48 > Para: Augusto Cabrera > CC: radiator@open.com.au > Asunto: Re: [RADIATOR] Problem Radiator configuration WIMAX > > On 03/02/2011 06:08 PM, Augusto Cabrera wrote: >> >> Hi I am configuring WiMAX radiator for authentication with the CPES are >> zyxel, but I have authentication errors please i need help, the setup I >> have is the following: > > Hello, > > can you tell us a bit more what the problem is? From the log below it > looks like there are TTLS authentication Access-Requests and > Access-Challenges, but there is no clear error as far as I can tell. > > If the error is TTLS authentication not finishing, you should check the > client configuration. Please check that the clients trust this root > certificate: > > EAPTLS_CAFile /etc/radiator/certificados/cacert.pem > > It is possible that the client does not recognize or trust the root > certificate and for that reasons stops the authentication process. It > looks like the TTLS inner authentication does not start so you should > concentrate on the certificate setup. > > Thanks! > Heikki > > >> [root@wimax radiator]# vi radius.cfg >> > 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 -- Heikki Vatiainen 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] AuthBy SQL results
On 03/03/2011 04:49 PM, Vangelis Kyriakakis wrote: > I would like to know what happens when AuthSelect query in AuthBy > SQL returns two or more rows. Which one is used? The first or the last? > Example: > > Username | Reply_item > --- > user | reply1 > user | reply2 > > AuthSelect select Reply_item from table where Username='user' > AuthColumnDef 0,GENERIC,reply > > Which reply_item is going to be used? Hello Vangelis, the answer is reply1. Even if the select returns multiple rows, only the first row is used. The rest of the rows are not saved or used later. Thanks! Heikki -- Heikki Vatiainen 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] Problem Radiator configuration WIMAX
r 4 14:34:03 2011: DEBUG: Packet dump:
> *** Sending to 3.3.3.3 port 10008
>
> Packet length = 57
> 0b cc 00 39 d4 a9 9e c5 5e b8 b8 45 0c 9a c8 7f
> 0b fa 43 c4 4f 13 01 e5 00 11 0d 80 00 00 00 07
> 15 03 01 00 02 02 28 50 12 f8 10 53 b9 59 78 52
> 8f 41 63 1b 33 98 a7 e9 eb
> Code: Access-Challenge
> Identifier: 204
> Authentic: <212><169><158><197>^<184><184>E<12><154><200><127><11><250>C<196>
> Attributes:
> EAP-Message = <1><229><0><17><13><128><0><0><0><7><21><3><1><0><2><2>(
> Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0>
>
> Fri Mar 4 14:34:03 2011: DEBUG: Rewrote user name to wimax@wimaxtest
> Fri Mar 4 14:34:03 2011: DEBUG: Rewrote user name to wimax@wimaxtest
> Fri Mar 4 14:34:03 2011: DEBUG: Packet dump:
> *** Received from 3.3.3.3 port 10008
>
> Packet length = 186
> 01 cd 00 ba 00 00 14 32 00 00 0b 28 00 00 49 cc
> 00 00 02 70 01 11 77 69 6d 61 78 40 77 69 6d 61
> 78 74 65 73 74 04 06 03 03 03 03 1f 0e 35 63 34
> 63 61 39 65 32 62 38 35 38 20 0a 57 41 53 4e 39
> 37 37 30 37 06 4d 71 3e c9 4f 08 02 e5 00 06 0d
> 00 1a 1a 00 00 60 b5 01 14 00 01 05 31 2e 31 02
> 03 02 03 03 01 05 03 01 04 03 01 1a 15 00 00 60
> b5 2e 0f 00 30 30 30 30 30 32 30 33 66 31 32 30
> 1a 0d 00 00 60 b5 03 07 00 ff ff b9 b0 3d 06 00
> 00 00 1b 1a 0f 00 00 60 b5 23 09 00 01 06 00 00
> 00 63 06 06 00 00 00 02 50 12 45 80 24 0c 47 0d
> 24 4b 46 4d bb 3d 45 79 ef 99
> Code: Access-Request
> Identifier: 205
> Authentic: <0><0><20>2<0><0><11>(<0><0>I<204><0><0><2>p
> Attributes:
> User-Name = "wimax@wimaxtest"
> NAS-IP-Address = 3.3.3.3
> Calling-Station-Id = "5c4ca9e2b858"
> NAS-Identifier = "WASN9770"
> Event-Timestamp = 1299267273
> EAP-Message = <2><229><0><6><13><0>
> WiMAX-Capability = <1><5>1.1<2><3><2><3><3><1><5><3><1><4><3><1>
> WiMAX-BS-ID = 0203f120
> WiMAX-GMT-Timezone-Offset = -18000
> NAS-Port-Type = Wireless-IEEE-802.16
> WiMAX-PPAC = <1><6><0><0><0>c
> Service-Type = Framed-User
> Message-Authenticator = E<128>$<12>G<13>$KFM<187>=Ey<239><153>
>
> Fri Mar 4 14:34:03 2011: DEBUG: Handling request with Handler
> 'Realm=DEFAULT', Identifier ''
> Fri Mar 4 14:34:03 2011: DEBUG: Deleting session for wimax@wimaxtest,
> 3.3.3.3,
> Fri Mar 4 14:34:03 2011: DEBUG: Handling with Radius::AuthSQL:
> Fri Mar 4 14:34:03 2011: DEBUG: Handling with Radius::AuthSQL:
> Fri Mar 4 14:34:03 2011: DEBUG: Query is: 'select reason from blacklist
> where nai='5c4ca9e2b858'':
> Fri Mar 4 14:34:03 2011: DEBUG: Radius::AuthSQL looks for match with
> 5c4ca9e2b858 [wimax@wimaxtest]
> Fri Mar 4 14:34:03 2011: DEBUG: Radius::AuthSQL REJECT: No such user:
> 5c4ca9e2b858 [wimax@wimaxtest]
> Fri Mar 4 14:34:03 2011: DEBUG: Query is: 'select reason from blacklist
> where nai='DEFAULT'':
> Fri Mar 4 14:34:03 2011: DEBUG: AuthBy SQL result: ACCEPT, No such user
> Fri Mar 4 14:34:03 2011: DEBUG: Handling with Radius::AuthWIMAX: AAA-WIMAX
> Fri Mar 4 14:34:04 2011: DEBUG: Handling with Radius::AuthWIMAX: AAA-WIMAX
> Fri Mar 4 14:34:04 2011: DEBUG: Handling with EAP: code 2, 229, 6, 13
> Fri Mar 4 14:34:04 2011: DEBUG: Response type 13
> Fri Mar 4 14:34:04 2011: DEBUG: EAP result: 1, TLS Alert acknowledged
> Fri Mar 4 14:34:04 2011: DEBUG: AuthBy WIMAX result: REJECT, TLS Alert
> acknowledged
> Fri Mar 4 14:34:04 2011: INFO: Access rejected for 5c4ca9e2b858: TLS Alert
> acknowledged
> Fri Mar 4 14:34:04 2011: DEBUG: Packet dump:
> *** Sending to 3.3.3.3 port 10008
>
> Packet length = 60
> 03 cd 00 3c c5 8a a5 01 f7 42 7b e2 06 16 fa cd
> 43 cf 06 f3 4f 06 04 e5 00 04 50 12 47 d3 77 e5
> 65 83 8e 92 87 5d 5b e2 f6 d8 4c a3 12 10 52 65
> 71 75 65 73 74 20 44 65 6e 69 65 64
> Code: Access-Reject
> Identifier: 205
> Authentic: <197><138><165><1><247>B{<226><6><22><250><205>C<207><6><243>
> Attributes:
> EAP-Message = <4><229><0><4>
> Message-Authenticator = <0><0><0><
Re: [RADIATOR] NTLM workstation authentication
On 03/18/2011 12:57 PM, Gianlu B wrote: > I'm trying to configure a Wireless with NTLM Authentication for the > machine/workstation (not user base Authentication). > I'm not able to configure that with ntlm_auth, not even on command line. Please check Radiator list archives, I think there have been discussions related to this. Would for example this help? http://www.open.com.au/pipermail/radiator/2010-October/016742.html > ### work > >Identifier USERAD >NtlmAuthProg /usr/sfw/bin/ntlm_auth --helper-protocol=ntlm-server-1 >EAPType MSCHAP-V2 > > > dont' work > >Identifier MACHINEAD >NtlmAuthProg /usr/sfw/bin/ntlm_auth > --helper-protocol=ntlm-server-1 --workstation="Workstations" >EAPType MSCHAP-V2 > > > > regards > Luca > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] Radiator support for NWG 1.2 Spec of WiMax Forum.
On 03/16/2011 11:39 AM, Rajesh Thota wrote: > Wondering if the current Radiator supports NWG 1.2 spec of the WiMax > Forum. If you need any further information on this specification do revert. I thought I'd let you know we are looking at this, but I do not have a definitive answer yet. Thanks! -- Heikki Vatiainen 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] radpwtest for EAP/TTL, EAP/TTLS and PEAP
On 03/22/2011 01:15 PM, Karl Gaissmaier wrote: >> eapol_test from the wpa_supplicant package can do lots of good things > > My nagios installation is running under Solaris 10 und I think > wpa_supplicant may not be supported for Solaris 10. You should try compiling eapol_test even if the host is running Solaris 10. If you disable all Linux and other OS specific settings from .config it seems to compile. I had problems with final linking, but I suspect this is more of a problem with the environment and I did not investigate further. My .config had these settings enabled which means e.g., CONFIG_DRIVER_ATMEL was commented out. CONFIG_BACKEND=file CONFIG_CTRL_IFACE=y CONFIG_EAP_GTC=y CONFIG_EAP_LEAP=y CONFIG_EAP_MD5=y CONFIG_EAP_MSCHAPV2=y CONFIG_EAP_OTP=y CONFIG_EAP_PEAP=y CONFIG_EAP_TLS=y CONFIG_EAP_TTLS=y CONFIG_IEEE8021X_EAPOL=y CONFIG_L2_PACKET=none CONFIG_PEERKEY=y CONFIG_PKCS12=y CONFIG_SMARTCARD=y > Would be nice if RADIATOR could test all supported AuthBy Handlers with the > radpwtest. That would duplicate lots of existing work from eapol_test. Please let us know of results if you decide to try to compile it on Solaris. Thanks! -- Heikki Vatiainen 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] RADMIN FOR TABLES THE WIMAX
On 03/22/2011 03:45 PM, Augusto Cabrera wrote: > Hi, I wonder if the normally functioning RADMIN to display Radiator > tables, also works for the WIMAX for that configuration tables, and as I > get to see through WIMAX web tables. The tables Radmin uses are not directly compatible with wimax tables. If you check goodies/radmin.cfg and wimax.sql you can see there are quite a lot of differences. I think directing Accounting messages to Radmin should work in case this would be useful to you. Best regards, Heikki -- Heikki Vatiainen 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] Radiator 4.7
On 03/24/2011 10:00 PM, David Hert wrote: > We recently built new RADIUS servers with Radiator 4.7...we have been > using 3.9. > > CentOs 5.5 with Radiator 4.7 > > I copied the Radiator config from the old servers to the new. For some > reason, the service have been randomly stopping. > I've looked in the logs and have not been able to identify a cause. > > A service restart seems to bring everything back up just fine. On > average, this has been happening once or twice a day. > > I was hoping that maybe you could offer a suggestion of things to > check or that maybe there is a known issue that could be addressed. > > Please let me know what you think. If you could run the server with Trace 4 the log should show why it stopped. That will probably write a large logfile, but searching for "NOTICE: Server started: Radiator 4.7" should quickly locate the lines near the event where the stop happend. This is what Radiator logs when it has started. I can then take a look at the log if needed. Best regards, Heikki -- Heikki Vatiainen 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] Radiator and two factor authentication using sms tokens
On 03/25/2011 11:23 AM, Bob Shafer wrote: > We've been thinking about two factor authentication, and, while I'm not > sure we would go that way, I found myself wondering about those > solutions that use SMS delivered tokens. > > In particular I was curious if there was anything happening with > Radiator in this area? There are AuthBy OTP, RSAMOBILE, RSAAM and DIGIPASS and examples for all in goodies/ directory. For example goodies/rsaam.cfg describes the OnDemand policy with a detailed example. Another example in goodies/radmin_otp_internode.cfg is for OTP with Ineternode's SMS gateway. A search for SMS in goodies/ directory will bring up all examples. Thanks! Heikki -- Heikki Vatiainen 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] Client MAC:xx-xx-xx-xx-xx-xx
On 03/28/2011 01:30 PM, Adam Bishop wrote: > Which attribute does radiator use for comparison when using > MAC-filtering on a client block? Trying to pin down why one of our > clients isn't being picked up by the client block we have set: The attribute is Calling-Station-Id. Its format is like what you have below with hyphens being optional. PreClientHook, section 5.4.27 in ref.pdf, runs before client lookup, so if needed you can try fixing C-S-I there. > > Secret SeekritKey > > > Filename %L/Seperate > Trace 4 > > -- Heikki Vatiainen 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] Client MAC:xx-xx-xx-xx-xx-xx
On 03/28/2011 02:39 PM, Christian Kratzer wrote: >>> Which attribute does radiator use for comparison when using >>> MAC-filtering on a client block? Trying to pin down why one of our >>> clients isn't being picked up by the client block we have set: >> >> The attribute is Calling-Station-Id. Its format is like what you have >> below with hyphens being optional. > > I just had a look at the code myself. It seems like it uses > Called-Station-Id: Good catch, thanks. That is true, and that is also what I was thinking. For some reason I still managed to type Calling :) > This is most propably the access points mac address on the air which is > not necessarily the same as the mac adresse seen on the ethernet. That's quite common too. With WLANs the SSID might also be added to the end of the MAC address. And in case of WLAN controllers the C-S-I may belong to the WLAN controller. Some controllers also have a setting with which you can choose to put controller or AP MAC address into Called-Station-Id. -- Heikki Vatiainen 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] RV: help Radiator support EVDO rev.A ?
On 03/24/2011 12:56 AM, Augusto Cabrera wrote: Hello Augusto, it looks like EVDO and its revisions specify the interface between the mobile station and its base station. So if you know Radiator supports EVDO and its previous versions, there is a good chance that it supports rev.A too. In other words, there is nothing EVDO specific in Radiator and if you can try and see if it works, please tell us about your result via this list. Thanks! Heikki > The version de my radiator is: Radiator-4.7-3 > > Augusto > > *De:* Augusto Cabrera > *Enviado el:* mié 23/03/2011 17:28 > *Para:* radiator@open.com.au > *CC:* radiator-requ...@open.com.au > *Asunto:* help Radiator support EVDO rev.A ? > > > Dear Radiator, > > Please your help to confirm if your software supports the authentication > for an EVDO Rev. A Network, we need that this software support the IMSI > distribution (the Radius should distribute IMSI), the radius should > support user group ), please confirm if this radius support template > management (for example to limite the bandwidth, user type, etc). > this radius support add user (include auth mode). > > Thanks for your kindly help > Augusto > -------- -- Heikki Vatiainen 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 resources...
On 03/25/2011 04:27 PM, Alan Buxey wrote: > just wondering what the impact on a RADIATOR server is for RADSEC clients > that are running in persistant TCP connection mode (as they seem to do by > default)... > how many of them can I operate in such a fashion against RADIATOR (4.7 with > patches) > or should they not be run in this mode? I would say this mode is preferred compared to establishing TLS sessions per request. Especially when requests are part of EAP session establishment for various TLS tunnelling protocols. > will it starve the resources of the RADIATOR for other tasks or will the > server > just spawn more children from the thread (hence my question about numbers). It will not spawn automatically, but you could try server farm if you think the number of clients should be split among Radiator servers. > dont want to find things go rapidly melty/wrong/shunoky when I reach > some mahical figure one afternoon.. Well, I do not know if anyone has hit RadSec imposed limit yet. Usually the problems seem to come from LDAP, SQL or some other processing or from AuthByPolicies which run through many AuthBys for each request. If the server is doing just proxying, then RadSec might be the limiting factor at some point, but for authenticating server, the limiting factor could also be the authentication backend. It would be interesting to hear about number of clients and authentication events if you plan to add a large number of clients. Yours, Heikki -- Heikki Vatiainen 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] Client MAC:xx-xx-xx-xx-xx-xx
On 03/28/2011 02:49 PM, Alan Buxey wrote: > PS RADIATOR folk, a few typos in your documents Thanks. Should be fixed when the next release comes out. -- Heikki Vatiainen 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] does OpenSSL 0.9.8n need patched for use with EAP-FAST?
On 03/30/2011 03:38 PM, Jim Veneskey wrote: > Does 0.9.8n contain the patches already that are required for EAP-FAST? > If not - is it recommended to downgrade to 0.9.8.e and attempt to > patch/install that version - or 0.9.9 ? > > I am guessing that the "Compilation failed in require..." shown below > is a result of my current OpenSSL setup - or is it because of something > else? EAP_43.pm has "use Digest::HMAC_SHA1;" Check first that you have this installed. If Digest::SHA1 does not come with that, you may want to install that too while installing packages. If the dependencies are correct, then we have to dig openssl change logs, but before that, check the above. Thanks! -- Heikki Vatiainen 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] does OpenSSL 0.9.8n need patched for use with EAP-FAST?
On 03/30/2011 05:49 PM, Jim Veneskey wrote: >> Wed Mar 30 10:34:50 2011: DEBUG: EAP result: 1, EAP-FAST Requires >> Net::SSLeay::set_session_secret_cb. Upgrade or patch your OpenSSL >> and/or Net-SSLeay >> Wed Mar 30 10:34:50 2011: DEBUG: AuthBy FILE result: REJECT, EAP-FAST >> Requires Net::SSLeay::set_session_secret_cb. Upgrade or patch your >> OpenSSL and/or Net-SSLeay >> Wed Mar 30 10:34:50 2011: INFO: Access rejected for anonymous: >> EAP-FAST Requires Net::SSLeay::set_session_secret_cb. Upgrade or patch >> your OpenSSL and/or Net-SSLeay >> Wed Mar 30 10:34:50 2011: DEBUG: Packet dump: > > Which implies that the version of openssl I was using - 0.9.8n was not > good enough. > > Just for fun - I upgraded openssl to the latest release: > >> openssl version >> OpenSSL 1.0.0d 8 Feb 2011 > And that also resulted in the messages shown above. 1.0.0d has support for the required functions. Here's what I have on openSUSE 11.3 % rpm -qa|grep -i sslea perl-Crypt-SSLeay-0.57-47.1.i586 perl-Net-SSLeay-1.36-3.1.i586 OpenSSL is 1.0.0 from March 29 2010 With the above I do not get complaints from missing functions. If you compiled openssl "./config shared" before the compile, the compilation creates shared libraries. You can point to those libs with something like export LD_LIBRARY_PATH=/home/hvn/src/openssl-1.0.0d When you start Radiator it should pick up the 1.0.0d ssl library. With something like above you can try to make sure Radiator is indeed using 1.0.0d unless you have purged the old version while installing 1.0.0d. > So - since I already had Net_SSLeay.pm-1.30 installed, my next step > looks to be downgrading OpenSSL to a supported version. Try upgrading Net-SSLeay.pm to 1.36. Version 1.30 is quite old and 1.36 does have the functions that are required. If Net_SSLeay 1.36 and openssl 1.0.0d do not work, I would downgrade to 0.9.8 with patches only then. > My question is - is there a preferred version out of the following four > that I should downgrade to? > >> openssl-0.9.8d-session-ticket-osc.patch >>openssl-0.9.8e-session-ticket-osc.patch >>openssl-0.9.8i-tls-extensions.patch >>openssl-0.9.9-session-ticket.patch I'm not completely sure. I can check, but plese try the above first. Thanks! -- Heikki Vatiainen 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] does OpenSSL 0.9.8n need patched for use with EAP-FAST?
On 03/31/2011 03:51 PM, Jim Veneskey wrote:
> I have gone back to openssl 1.0.0d and installed newer versions of the
> modules.
Ok, I did also some testing. Please see below for more.
> Attached is a full log of my test session, including the radius.cfg and
> users file I am using.
> My radius.cfg is basically the example one found in goodies/.
Same here.
> I am testing the setup using a Windows client running Funk Odyssey and I
> have verified that
> the credentials I am using on the client match what is in the users file.
>
> Funk will prompt me to acquire new EAP-FAST credentials, however, when
> I instruct it to do so - it just
> keeps popping back up.
I tested with eapol_test from wpa_supplicant package. Here's the
configuration I used:
network={
ssid="eapol"
proto=WPA2
pairwise=CCMP
key_mgmt=WPA-EAP
eap=FAST
anonymous_identity="hvn"
identity="hvn"
password="password"
ca_cert="cacert.pem"
phase1="fast_provisioning=2"
pac_file="wpasupplicant.eap-fast-pac"
phase2="autheap=MSCHAPV2"
#dh_file="dh2048.pem"
}
Command was: ./eapol_test -p1645 -s mysecret -c eapol-eap-fast.conf
If run twice, it will succeed. The first run fetches the pac file and
then subsequent logins will succeed.
> It appears to be failing here: (for full trace - see attachment)
Same here if I run it when there is no pac_file and fast_provisioning is
set to 1. The MSCHAP calculated challenge response does not match what
was expected.
>> Thu Mar 31 08:29:51 2011: DEBUG: Radius::AuthFILE ACCEPT: : anonymous
>> [anonymous]
It got the user and its password from users file.
>> Thu Mar 31 08:29:51 2011: DEBUG: EAP result: 1, EAP MSCHAP-V2
>> Authentication failure
Challenge was not what was expected.
> At this point, I am not sure if I now have Radiator configured properly,
> and the issue is with my client.
The Radiator configuration should be good. I think this is related to
what happens or does not happens during pac provisioning. I'll try with
a different client, iPod, later to see how it behaves.
> Radiator is not displaying any errors about modules any more - so I'm
> guessing it may be configured properly?
Thanks!
Heikki
--
Heikki Vatiainen
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] hung processes when "Bad authenticator received in reply" using AuthBy RADIUS with Synchronous and Fork
On 03/25/2011 12:12 AM, David Zych wrote: > I noticed today when using AuthBy RADIUS with Synchronous and Fork > that if the secrets don't match (resulting in "Bad authenticator > received in reply to ID 1. Reply is ignored"), this creates forked > processes that never terminate and have to be manually force-killed. > > From what I can tell, it appears that AuthRADIUS::handleReply removes > the timeout but does not set RadiusResult to tell Synchronous mode > that it's finished. Presumably it needs to do both of these things > or neither. David, thanks for investigating and reporting this. The patch for this was commited recently and is available in the patch set for 4.7. Thanks! -- Heikki Vatiainen 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] packet tracer
On 03/28/2011 05:04 PM, Bart Dumon wrote: > enjoy.. > > > #!/usr/bin/perl > # > # 2011-03-24 rpt.pl - radiator packet tracer - Bart Dumon - > bartdu(at)bsp(dot)scarlet(dot)be > # match anything in request packet(s), shows corresponding response packet(s) > # requires a clause, cfr section 5.91 of the Radiator manual rpt.pl is now also among goodies/ in the latest patch set for 4.7. Thanks! -- Heikki Vatiainen 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] Client MAC:xx-xx-xx-xx-xx-xx
On 03/29/2011 06:02 PM, Adam Bishop wrote: > It seems that it was not being detected as the NAS is appending its SSID > to the C-S-I. > > Rather than using a hook, I have taken the line terminators out of the > regex and it seems to give the intended behaviour (I don't really want to > strip the AP name as it is useful metadata, though writing it to another > attribute is an option (Real-Called-Station-ID?)). > > I wonder if pulling the MAC out of C-S-I is something radiator should do > by default regardless of its formatting as far as possible (adjusting the > regex to pick up MAC's "in-line", and allowing for - : and maybe . as > separators), as it seems that most AP's do append the SSID. There is now a patch in the latest patch set for 4.7 that should pick up the MAC when the SSID is there. It does not try to work with all possible formats but it does allow the format recommended in RFC 3580 Client addresses in the form MAC:nn-nn-nn-nn-nn-nn now work even if the Called-Station-Id has the SSID of the AP appended as described in http://tools.ietf.org/html/rfc3580#section-3.20 > There are a number of limitations to using MAC client identification > anyway (spoofing etc.) so I don't think changing this behaviour would > cause any repercussions, as anyone who is using is _should_ understand its > weaknesses. Thanks! Heikki -- Heikki Vatiainen 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] DigiPass Static PIN Reset for Go-7?
On 04/04/2011 07:44 PM, Linuxchuck wrote: > Time for a DigiPass token question. I have a box of 125 brand-new > DigiPass Go-7 tokens that I have imported into our production > Radiator server, and they work just fine. My question is: Is the > static password change procedure as outlined in the documentation > applicable to Go-7 tokens? The doc states "Go-1 and Go-3 tokens > (among others) also support the ability to change your PIN.". Would > the Go-7 be one of those that are "among others"? We do not have any Go-7 cards here, but we expect consistent behaviour with other tokens. However, support of PINs is dependent on that option being enabled in the card's import record (ie by Vasco), and the PIN options that might be configured there. You should check the import records for these tokens. > If so, I seem to have run into a snag trying the process. The trace > 4 log shows an error of "DEBUG: Radius::AuthSQLDIGIPASS REJECT: > Digipass Authentication failed: Response Too Long" when I attempt a > PIN reset based on the documentation. Please let us and the list know if you get PIN change to work. Thanks! -- Heikki Vatiainen 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] radiator Timeout handling
On 04/06/2011 10:22 PM, David Zych wrote:
David,
thanks for the suggestion and comments. Please see my comments below:
> I just ran into this same problem; my DB got into a state where
> DBI->connect was working fine but actual INSERTs were timing out, and
> the non-observance of FailureBackoffTime in this situation resulted in
> both of my RADIUS servers being effectively stalled for 10 minutes (one
> INSERT Timeout at a time) until the DB issue was resolved.
Patches for 4.7 has this:
2010-09-21 SqlDb.pm
Added SQLRetries parameter to all SQL type clauses. When executing a
query, Radiator will try up to SQLRetries attempts to execute the query,
retrying if certain types of SQL error are seen. Defaults to 2.
Requested by Michael.
Would this be helpful? You can also control the timeout with a
parameter, see ref.pdf "5.29.4 Timeout", unless you platform is Win32.
So if you set retries to 1 and Timeout to a small number of seconds,
would this be a solution? SQLRetries works with Win32 too.
> I would like to second Michael's request for a way to alter this behavior.
>
> It appears that right now SqlDb.pm has a single $self->{backoff_until}
> timer that applies collectively to all configured DBSources (i.e. it is
> set only when all DBSources fail DBI->connect in sequence, and when set
> it causes none of them to be tried again in reconnect() until the set
> time). Would it perhaps make more sense that:
A couple of notes about what is shared.
SqlDB.pm uses $self->{backoff_until} but $self varies. In other words,
if you have a LogSQL, an AuthLogSQL and an AuthBySQL they all inhert
from SqlDb.pm, have different $self and for that reason different
$self->{backoff_until} too.
What is shared are the prepared statement handles and database handles.
If you have the same "$dbsource;$dbusername;$dbauth" for e.g. LogSQL and
AuthBySQL then you are using the same handle for both.
> 1. each configured DBSource gets its own individual backoff_until timer
> that is set when that DBSource fails DBI->connect, and when set causes
> that DBSource to be skipped in reconnect() until the set time.
>
> 2. individual statement timeouts, such as the one in SqlDb::do(), could
> also set the backoff_until timer for the individual DBSource currently
> in use. If this is judged not to be desirable in the general case, it
> could be controlled by a separate configuration parameter
> ("TimeoutBackoffTime", perhaps?).
>
> I'm half tempted to try to implement this myself, but I'm not confident
> that I fully understand all the potential repercussions for other parts
> of Radiator, and I know I'm not in a good position to test it thoroughly.
We'll take a look at your comments in more detail. If you plan to
implement the changes, please let us know of your results.
Thanks again!
--
Heikki Vatiainen
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] AuthBy LDAP2, HoldServerConnection and missing Retry parameter
On 04/06/2011 03:39 PM, Christian Kratzer wrote: >> Wed Apr 6 00:32:34 2011: ERR: ldap search for (|(mail=foo)(uid=bar)) failed >> with error LDAP_SERVER_DOWN. >> Wed Apr 6 00:32:34 2011: ERR: Disconnecting from LDAP server (server >> foo.uni-ulm.de:636). >> Wed Apr 6 00:32:34 2011: DEBUG: AuthBy LDAP2 result: IGNORE, User database >> access error > > this is strange as Radiator-4.x has explicit support for reconnecting > to ldap servers after an idle timeout. Indeed. The function that has "ldap search for ..." error message does LDAP reconnect as the first thing. Reconnect should notice the closed connection and then connect again. It might be a good idea to upgrade since the newer versions might do better job with sending notices about the disonnect. If upgrade is not possible, then commenting out HoldServerConnection will probably help too. >> See the config part below: >> >> >> PacketTrace >> HoldServerConnection >> NoDefault >> >> Hostfoo.uni-ulm.de >> Version 3 >> FailureBackoffTime 3 >> >> UseSSL >> SSLVerify require >> SSLCAFile %D/certificates/ca-bundle.crt >> >> AuthDN cn=secret >> AuthPasswordmore-secret >> >> BaseDN ou=bar,dc=uni-ulm,dc=de >> Scope one >> >> # username oder e-mail >> SearchFilter(|(mail=%1)(uid=%1)) >> PasswordAttruserPassword >> > > Perhaps as you only have one ldap server to forward to you should set > FailureBackoffTime to 0 to allow radiator to immediatly to reconnect. > > Casual reading of the source code makes me think this might be the problem. > > >> HINTS: >> >> I didn't see this problem with RADIATOR 3.11. >> Sigh, I can't go back to 3.11 to verify it definitely. >> Sigh, I know, it's a big step from 3.11 to 4.7. >> >> The LDAP server didn't change during the RADIATOR upgrade. >> We are using an openldap-2.3.35 under SunOS 5.10 and openssl-0.9.8-latest. > > As a side note and nothing to do with your current problem. > > Latest stable is openldap-2.4.23 and latest released is 2.4.25. You > should consider updating for anything but a trivial directory setup. > There have been lots of fixes since openldap 2.3. > > Greetings > Christian > -- Heikki Vatiainen 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] Password Retry / Password Change For TTLS MsChapV2
On 04/06/2011 07:33 PM, Aman Arneja wrote: > I am trying to find out if radiator supports Password Retry and Password > Change scenarios ( For expired password) with TTLS Mschapv2 ( as Non Eap > Method) If so can some1 please guide me as to how to configure the server > for these options? If not what would be the easiest method to add support > for the same. I need to test some scenarios around this and the client i am > using supports these features. Password Retry or Change are not currently supported for EAP or non-EAP versions of MSCHAPv2. I can check if there are any plans for the future support and I will then get back to you. Best regards, Heikki -- Heikki Vatiainen 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] Windows Server 2008 R2
On 04/06/2011 05:09 PM, Remco van Noorloos wrote: > We are planning to install Radiator on a Windows Server 2008 R2 > server. I checked the reference manual but only Windows Server 2003 > is mentioned as supported. Is Windows Server 2008 supported or should > I use a Windows 2003 server? I have myself used Windows Server 2008. I do not see any reason why 2008 R2 should not work too. The main thing is ActivePerl. If ActivePerl works well, then Radiator should not be a problem. If there are problems, then there is the option of going back to 2003. Best regards, Heikki -- Heikki Vatiainen 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] Problem with %{Reply,name}
On 04/07/2011 10:13 PM, frank.mes...@osix.nl wrote:
> USER_CATEGORY,{Reply,Class},formatted
Try %{Reply:Class}. You need % sign and : instead of ,
--
Heikki Vatiainen
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] Loading configuration dynamically from SQL database
kend, request
AuthColumnDef 1, backend-var-1, request
...
Identifier sql-add-reply-attributes
AuthSelect SELECT ...
AuthColumnDef 0, reply-attr-1, reply
...
AuthByPolicy ContinueWhileAccept
AuthByPolicy ContinueUntilAccept
AuthBy sql-check-username
AuthBy sql-check-realm
HandlerId auth-user-%{backend}
AuthBy sql-add-reply-attributes
Identifier auth-user-ldap
BaseDn %{backend-var-1}
...
Identifier auth-user-sql
DBSource %{backend-var-1}
...
--
Heikki Vatiainen
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] Problem with %{Reply,name}
On 04/08/2011 07:30 PM, frank.mes...@osix.nl wrote: Hello Frank, > As described in my earlier mail I want to add an attribute in the reply > message as follows > > AuthSelect select PASSWORD, USER_CATEGORY from DSM_USER where > DOMAIN_NAME = 'PUBLIC' AND USER_NAME = split_part (%0,E'\\', 2) AND > ENABLED = True > > AuthColumnDef 0, User-Password, check > AuthColumnDef 1, Class, reply That looks good and should work. You probably checked Radiator log and verified that Class gets sent with Access-Accept? > However, I don't get this Class attribute back in the accounting response. > I would expect that every NAS (we are using Coova Chilli) would handle > this Class attribute, but apparently it does not. That is a very reasonable expectation. The clients should just echo back Class with Accounting messages in effect binding the authentication event the respective accounting session. > Are these reply attributes NAS specific ? No. Class is in the base RADIUS RFC. See for example this: http://tools.ietf.org/html/rfc2865#section-5.25 > Should I use another attribute ? You could check Coova documentation to see if they support anything similar to Class. If they do not, User-Name attribute should behave similarly to Class. See for example: http://tools.ietf.org/html/rfc2865#section-5.1 It's of course usually more useful to keep User-Name intact. Thanks! Heikki -- Heikki Vatiainen 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] Loading configuration dynamically from SQL database
= "203.63.154.1" > NAS-Port = 1234 > Called-Station-Id = "123456789" > Calling-Station-Id = "987654321" > NAS-Port-Type = Async > User-Password = <158><252>xt"cP<217><217><197><4><229><208>-<6>; > > Mon Apr 11 10:02:41 2011: DEBUG: Handling request with Handler '', Identifier > '' > Mon Apr 11 10:02:41 2011: DEBUG: Deleting session for > rvannoorl...@proxsys.net, 203.63.154.1, 1234 > Mon Apr 11 10:02:41 2011: DEBUG: Handling with Radius::AuthGROUP: > Mon Apr 11 10:02:41 2011: DEBUG: Handling with Radius::AuthSQL: > DETERMINE_AUTH_BACKEND > Mon Apr 11 10:02:41 2011: DEBUG: Handling with Radius::AuthSQL: > DETERMINE_AUTH_BACKEND > Mon Apr 11 10:02:41 2011: DEBUG: Query is: 'EXEC spGetAuthenticationSource > 'rvannoorl...@proxsys.net', 'Async', 'Framed-User', ''': > Mon Apr 11 10:02:41 2011: DEBUG: Radius::AuthSQL looks for match with > rvannoorl...@proxsys.net [rvannoorl...@proxsys.net] > Mon Apr 11 10:02:41 2011: DEBUG: Radius::AuthSQL ACCEPT: : > rvannoorl...@proxsys.net [rvannoorl...@proxsys.net] > Mon Apr 11 10:02:41 2011: DEBUG: Radius::AuthGROUP: DETERMINE_AUTH_BACKEND > result: ACCEPT, > Mon Apr 11 10:02:41 2011: DEBUG: AuthBy GROUP result: ACCEPT, > Mon Apr 11 10:02:41 2011: DEBUG: Handling with Radius::AuthHANDLER: > Mon Apr 11 10:02:41 2011: DEBUG: AuthBy HANDLER is redirecting to Handler > 'AUTH_USER_realmLDAP' > Mon Apr 11 10:02:41 2011: DEBUG: Handling request with Handler '', Identifier > 'AUTH_USER_realmLDAP' > Mon Apr 11 10:02:41 2011: DEBUG: Deleting session for > rvannoorl...@proxsys.net, 203.63.154.1, 1234 > Mon Apr 11 10:02:41 2011: DEBUG: Handling with Radius::AuthSQL: > Mon Apr 11 10:02:41 2011: DEBUG: Handling with Radius::AuthSQL: > Mon Apr 11 10:02:41 2011: DEBUG: Query is: 'EXEC spLDAPGetProperties > 'rvannoorl...@proxsys.net', 369': > Mon Apr 11 10:02:41 2011: DEBUG: Radius::AuthSQL looks for match with > rvannoorl...@proxsys.net [rvannoorl...@proxsys.net] > Mon Apr 11 10:02:41 2011: DEBUG: Radius::AuthSQL ACCEPT: : > rvannoorl...@proxsys.net [rvannoorl...@proxsys.net] > Mon Apr 11 10:02:41 2011: DEBUG: AuthBy SQL result: ACCEPT, > Mon Apr 11 10:02:41 2011: DEBUG: Handling with Radius::AuthLDAP2: > Mon Apr 11 10:02:41 2011: INFO: Connecting to :389 > Mon Apr 11 10:02:41 2011: ERR: Could not open LDAP connection to :389. > Backing off for 1 seconds. > Mon Apr 11 10:02:41 2011: DEBUG: AuthBy LDAP2 result: IGNORE, User database > access error > Mon Apr 11 10:02:41 2011: DEBUG: AuthBy HANDLER result: IGNORE, User database > access error -- Heikki Vatiainen 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] Status of Status-Server
On 04/09/2011 01:26 AM, Alan Buxey wrote: > just wondering what the current status or implementation level > of Status-Server in RADIATOR for remote proxy AuthBy handlers? It is implemented for Client side only. For example, AuthBy RADIUS clause does not contain code to send Status-Server requests to the next hop. > I know the server can send stuff back to a Client (which may use Status-Server > to detect if the RADIATOR is alive rather than just relying on a > response to a packet sent to determine if server is okay or not..) > but wondering if there are any methods/hooks for the server to throw > a status-server to the AuthBy RADIUS/RADSEC remote proxy to see if its > alive rather than rely on timers and reply timeouts for the behaviour - I am not aware of any hooks that have already been written to handle this. I think it could be possible to create a hook that does it. Maybe a pair of NoReplyHook and ReplyHook. If a request times out, the NoReplyHook could send out Status-Server and ReplyHook could then process it. I have not checked the details, but that might be one way to send a Status-Server. > we have a multi tier proxy architecture and it just takes one random > badly configured site in the scheme for all sorts of nasty things to > start occuring to a proxy in the middle of it. I guess its RADIATOR > dealing with Status-Server s a client rather than dealing with it > FROM clients :-) Have you checked DeadRealmMarking? http://www.eduroam.cz/dead-realm/docs/dead-realm.html It's been very helpful for making sure one unresponsive endsite or proxy does not kill the perfectly functioning next hop radius server. Yours, Heikki -- Heikki Vatiainen 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] AuthBy LDAP2, HoldServerConnection and missing Retry parameter
On 04/11/2011 12:26 PM, Karl Gaissmaier wrote: >>> this is strange as Radiator-4.x has explicit support for reconnecting >>> to ldap servers after an idle timeout. >> >> Indeed. The function that has "ldap search for ..." error message does >> LDAP reconnect as the first thing. Reconnect should notice the closed >> connection and then connect again. > > but not with HoldSeverConnection, or? I don't see a reconnect, > not under Trace 4 and even not on the wire with wireshark. With HoldServerConnection, yes. When HoldServerConnection is defined and there should be an active ldap handle, the code checks if the socket is still ok or it the socket indicates that there is something available. If this something is LDAP_OPERATIONS_ERROR with "Unexpected EOF" then there should be a reconnect. Before this check, the the code checks if the socket is still connected. This should take care of e.g., timeouts caused by firewalls. Thanks, Heikki -- Heikki Vatiainen 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] Loading configuration dynamically from SQL database
On 04/11/2011 05:13 PM, Remco van Noorloos wrote:
> Currently we have 100+ LDAP servers we're authenticating with. So if
> we have to edit the config file in order to make a change that
> wouldn't be manageable for us and is a situation we really like to
> avoid.
That is very understandable.
One way to do this would be to generate automatically all the AuthBys
and then use Include to pull them in Radiator configuration.
> From what I understand the implementation isn't really uniform? Since
> some parameters can be set dynamically and others not?
Most things can be set dynamically so it is uniform in that sense. What
is not uniform is what the lifetime (for the better word) of various
parameters is.
The userid in search parameter varies from request to request, naturally.
AuthDN can be initialised when the first request arrives, but within one
AuthBy LDAP2, the AuthDN stays the same between request so that there is
not a separate bind operation for each request.
Host parameter can be set from a global variable, but that is when
Radiator starts or is reinitialised.
> In addition, when I use the following Handler the same problem
> occurs. In this snippet the 'CONNECTION_ID' is empty, this attribute
> is set in the ' DETERMINE_AUTH_BACKEND' AuthBy as included in my last
> mail.
Try Acct-Session-Id - notice the spelling.
Also, you are using AuthSelect with DETERMINE_AUTH_BACKEND and using
Acct-Session-Id as a part of AuthSelect. Since this select runs by
default for authentication requests, does it have access to
Acct-Session-Id parameter?
You should see from the log what happens. AuthSelect should be formatted
for each request, so %{CONNECTION_ID} should contain the value from the
request.
>
> Identifier AUTH_USER_realmSQL
>
> #
> # Perform SQL authentication
> #
>
> DBSourcedbi:ODBC:DRIVER={SQL
> Server};SERVER={%{GlobalVar:DB_PMS_SERVER}};DATABASE=%{GlobalVar:DB_PMS_NAME}
> DBUsername %{GlobalVar:DB_PMS_USER}
> DBAuth %{GlobalVar:DB_PMS_PASSWORD}
>
> AuthSelect EXEC spPasswdSelect %{CONNECTION_ID},
> %{Quote:%{Acct-Session-ID}}
> AuthColumnDef 0, User-Password, check
> AuthColumnDef 1, CONNECTION_ID, request
>
>
>
--
Heikki Vatiainen
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] [Radiator] EAP TTLS with EAP Inner Method
On 04/11/2011 03:55 PM, Aman Arneja wrote: > As you might have gathered from my previous mails, i am writing an EAP > TTLS Method. We are facing problems with using EAP Inner Methods. Non > Eap Inner methods are working fine. I am attaching 2 log files : > > 1.) radiatornoproxy : Config File = eap_ttls.cfg. > Topology : > Client - Wireless supplicant configured to authenticate using our TTLS + > EAP MsChapv2 > Radiator - AuthByLsa > > 2.) eapttlsradiator : Config File = eap_ttls_proxy.txtTopology : > Client - Wireless supplicant configured to authenticate using our TTLS + > EAP MsChapv2 > Radiator - AuthByRadius, with authentication terminating on Microsoft NPS > > In Both Cases Radiator is rejecting the AVP sent by client after server > sends access challenge. >From the log it looks like Radiator sends access challenge inside the tunnel as you say: EAP-Message = <1><7><0>)<26><1><7><0>$<16><23><206>c<129><234><225>n<214><201><243>f<208><248><184><20><219>RadiatorServer1 This seems to be a well formed EAP-MSCHAP-V2 challange according to http://tools.ietf.org/html/draft-kamath-pppext-eap-mschapv2-02 But when the response comes, Radiator does not even get to process it as an AVP but the underlying TLS processing indicates there is a "wrong version number" as seen below. In other words, it looks like after the client receives Radiator's tunnelled EAP-MSCHAP-V2 challenge, the tunnelling TLS thinks the received TLS record is faulty. A quick check shows that "wrong version number" could mean a mismatch between expected and received SSL 3.0 and TLS 1.x version. However, for me it looks like the version is alwasy <3><1> which is TLS 1.0. So it looks like SSL/TLS library Radiator uses sees something it does not like. > Can some1 pls help us with this? Let me know if any more information is > required. Seems to be an issue with the reading of the EAP Message from > the AVP. I would say it is a TLS problem. Though I am not sure what exactly. Best regards, Heikki > Snipped of issue is as follows > : > Mon Apr 11 04:34:01 2011: DEBUG: Handling request with Handler '', > Identifier '' > > Mon Apr 11 04:34:01 2011: DEBUG: Deleting session for > DVM-AMARNE-DC\anonymous, 192.168.10.3, 0 > > Mon Apr 11 04:34:01 2011: DEBUG: Handling with Radius::AuthFILE: > > Mon Apr 11 04:34:01 2011: DEBUG: Handling with EAP: code 2, 7, 139, 21 > > Mon Apr 11 04:34:01 2011: DEBUG: Response type 21 > > Mon Apr 11 04:34:01 2011: DEBUG: EAP TTLS data, 3, 7, 6 > > Mon Apr 11 04:34:01 2011: DEBUG: EAP result: 1, EAP TTLS read failed: > 1168: 1 - error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number > > Mon Apr 11 04:34:01 2011: DEBUG: AuthBy FILE result: REJECT, EAP TTLS > read failed: 1168: 1 - error:1408F10B:SSL > routines:SSL3_GET_RECORD:wrong version number > > Mon Apr 11 04:34:01 2011: INFO: Access rejected for > DVM-AMARNE-DC\anonymous: EAP TTLS read failed: 1168: 1 - > error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number > > Mon Apr 11 04:34:01 2011: DEBUG: Packet dump: > > *** Sending to 192.168.10.3 port 65529 > > Code: Access-Reject > > Identifier: 6 > > Authentic: > <179>~<25><150><242><188><191><189>_<127><180><130>O<26><21><209> > > Attributes: > > EAP-Message = <4><7><0><4> > > Message-Authenticator = <0><0><0><0><0><0><0><0><0><0><0><0><0><0><0><0> > > Reply-Message = "Request Denied" > > Thanx > > > > Aman Arneja > > > > > > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator -- Heikki Vatiainen 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] Loading configuration dynamically from SQL database
gt; prepared. (SQL-42000)
> Tue Apr 12 14:53:36 2011: DEBUG: Radius::AuthSQL looks for match with
> prox1-a...@dsl.proxsys.net [prox1-a...@dsl.proxsys.net]
> Tue Apr 12 14:53:36 2011: DEBUG: Radius::AuthSQL REJECT: No such user:
> prox1-a...@dsl.proxsys.net [prox1-a...@dsl.proxsys.net]
> Tue Apr 12 14:53:36 2011: DEBUG: Query is: 'EXEC spPasswdSelect , ''':
> Tue Apr 12 14:53:36 2011: ERR: Execute failed for 'EXEC spPasswdSelect , ''':
> [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near ','.
> (SQL-42000)
> [Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not be
> prepared. (SQL-42000)
> Tue Apr 12 14:53:36 2011: ERR: Execute failed for 'EXEC spPasswdSelect , ''':
> [Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near ','.
> (SQL-42000)
> [Microsoft][ODBC SQL Server Driver][SQL Server]Statement(s) could not be
> prepared. (SQL-42000)
> Tue Apr 12 14:53:36 2011: DEBUG: AuthBy SQL result: REJECT, No such user
> Tue Apr 12 14:53:36 2011: DEBUG: AuthBy HANDLER result: REJECT, No such user
> Tue Apr 12 14:53:36 2011: INFO: Access rejected for
> prox1-a...@dsl.proxsys.net: No such user
> Tue Apr 12 14:53:36 2011: DEBUG: Packet dump:
> *** Sending to 127.0.0.1 port 1739
> Code: Access-Reject
> Identifier: 141
> Authentic: e<252><160><164><169>q(<223>lm<221>0<142>p<135><31>
> Attributes:
> Reply-Message = "Request Denied"
>
> -Oorspronkelijk bericht-
> Van: Heikki Vatiainen [mailto:h...@open.com.au]
> Verzonden: dinsdag 12 april 2011 14:43
> Aan: Remco van Noorloos
> CC: radiator@open.com.au
> Onderwerp: Re: [RADIATOR] Loading configuration dynamically from SQL database
>
> On 04/11/2011 05:13 PM, Remco van Noorloos wrote:
>
>> Currently we have 100+ LDAP servers we're authenticating with. So if
>> we have to edit the config file in order to make a change that
>> wouldn't be manageable for us and is a situation we really like to
>> avoid.
>
> That is very understandable.
>
> One way to do this would be to generate automatically all the AuthBys
> and then use Include to pull them in Radiator configuration.
>
>> From what I understand the implementation isn't really uniform? Since
>> some parameters can be set dynamically and others not?
>
> Most things can be set dynamically so it is uniform in that sense. What
> is not uniform is what the lifetime (for the better word) of various
> parameters is.
>
> The userid in search parameter varies from request to request, naturally.
>
> AuthDN can be initialised when the first request arrives, but within one
> AuthBy LDAP2, the AuthDN stays the same between request so that there is
> not a separate bind operation for each request.
>
> Host parameter can be set from a global variable, but that is when
> Radiator starts or is reinitialised.
>
>> In addition, when I use the following Handler the same problem
>> occurs. In this snippet the 'CONNECTION_ID' is empty, this attribute
>> is set in the ' DETERMINE_AUTH_BACKEND' AuthBy as included in my last
>> mail.
>
> Try Acct-Session-Id - notice the spelling.
>
> Also, you are using AuthSelect with DETERMINE_AUTH_BACKEND and using
> Acct-Session-Id as a part of AuthSelect. Since this select runs by
> default for authentication requests, does it have access to
> Acct-Session-Id parameter?
>
> You should see from the log what happens. AuthSelect should be formatted
> for each request, so %{CONNECTION_ID} should contain the value from the
> request.
>
>>
>> Identifier AUTH_USER_realmSQL
>>
>> #
>> # Perform SQL authentication
>> #
>>
>> DBSourcedbi:ODBC:DRIVER={SQL
>> Server};SERVER={%{GlobalVar:DB_PMS_SERVER}};DATABASE=%{GlobalVar:DB_PMS_NAME}
>> DBUsername %{GlobalVar:DB_PMS_USER}
>> DBAuth %{GlobalVar:DB_PMS_PASSWORD}
>>
>> AuthSelect EXEC spPasswdSelect %{CONNECTION_ID},
>> %{Quote:%{Acct-Session-ID}}
>> AuthColumnDef 0, User-Password, check
>> AuthColumnDef 1, CONNECTION_ID, request
>>
>>
>>
>
>
--
Heikki Vatiainen
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
