[RADIATOR] Automated Reply : Thomas Kurian is out of station
Dear Sender, Thank you for your e-mail. Kindly be informed that I am currently out of station and will be back on Sunday June 5th 2016. During this period, I'll have no access to e-mails and limited phone access. For matters requiring immediate attention, you are kindly requested to contact Mr. Hakim for both General Sales and Technical support queries. Contact Details are as follows : Mr Hakim's Email ID : ha...@kccg.com KCCG Office Phone No. : +965 22435566 -- Best Regards, Thomas Kurian IT Security Consultant Kuwaiti Canadian Consulting Group (www.kccg.com) T: +965 22435566 F: +965 22415149 E: tho...@kccg.com ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] ServerTACACSPLUS logging improvements
On 31.5.2016 12.57, Hartmaier Alexander wrote: >>> - Could not get peer name on TacacsplusConnection socket: Transport >>> endpoint is not connected >> Hmm, that's happening very early withing server tacacsplus, so there's >> no request, client, etc is available yet. Improvements here may be >> small, if any. > Than please at least add more information to the error message itself so > that at least the misbehaving client can be identified. Hmm, do you get these often? Also, does your configuration have FarmSize enabled? This error occurs very early after the new connection has been accepted. The code tries to figure out the address and port of the client, but getpeername call fails. I noticed the accept for the new connection is done slightly differenty than what the StreamServer class does, so I was thinking if this is something StreamServer does better in farm size environments. I'll see if there's anything more that can be logged too. 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] ServerTACACSPLUS logging improvements
On 2016-05-30 11:31, Heikki Vatiainen wrote: > On 27.5.2016 16.04, Hartmaier Alexander wrote: > >> The log messages emitted by ServerTACACSPLUS sadly lack all the standard >> Radius attributes like Handler:Identifier, User-Name, Client-Identifier etc. >> Is there a way to improve this situation? > We can, and have already thought about, adding $p (the current request > object, or sometimes $rp, the reply object) to a number of log messages > that happen within message context. That is, where $p or $rp is available. > > The request/reply object should provide more information about handlers, > clients, etc. That would be great! > >> The log messages in question are: >> - Could not get peer name on TacacsplusConnection socket: Transport >> endpoint is not connected > Hmm, that's happening very early withing server tacacsplus, so there's > no request, client, etc is available yet. Improvements here may be > small, if any. Than please at least add more information to the error message itself so that at least the misbehaving client can be identified. > >> - Authorization permitted for $USERNAME at $IPADDR, group $GROUPNAME, >> args service=shell cmd* > Should be possible, not completely sure yet though. Access to $p and $rp would solve the problem here as well I guess. > >> But there are also non-ServerTACACSPLUS messages that don't include >> those infos where it would be nice to know which Handler/AuthBy >> trigggered them (those come from an AuthBy LDAP2, but which one?): >> - Connecting to 1.2.3.4:636 1.2.3.5:636 >> - Connected to 1.2.3.4:636 >> - Attempting to bind to LDAP server 1.2.3.4:636 > These should be possible. Sometimes, for example with ClientList LDAP, > the functions that log these are not called within message context. In > other words, depending on the log caller, the call may or may not > include the request that provides Client etc, information. > > I'll notify via this list when I have more information about these > > Thanks, > Heikki > Thank you very much Heikki!!! *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
