Hi Daniel, we generate the Client config blocks using ClientListSQL from our NMS database. The identifier is the hostname and we use the OSC-Group-Identifier set to the support group name for further distinguishment in the handlers.
We also add other metadata like OSC-Customer-Identifier for logging this way. Best regards, Alex On 2016-09-08 07:12, Hugh Irvine wrote: > Hello Daniel - > > You can use Identifiers in your Client clauses to indicate what sort of > device they are, then use those identifiers in your Handlers. > > Something like this: > > …… > > <Client 1.1.1.1> > Identifier Firewall > ….. > </Client> > > <Client 2.2.2.2> > Identifier Firewall > ….. > </Client> > > <Client 3.3.3.3> > Identifier Switch > ….. > </Client> > > <Client 4.4.4.4> > Identifier Switch > ….. > </Client> > > ….. > > <Handler Client-Identifier = Firewall, NAS-Identifier = TACACS> > AuthByPolicy ContinueUntilAccept > AuthBy CheckReadOnlyAccessForFirewall > AuthBy CheckFullAccessForFirewall > </Handler> > > <Handler Client-Identifier = Switch, NAS-Identifier = TACACS> > AuthByPolicy ContinueUntilAccept > AuthBy CheckReadOnlyAccessForSwitch > AuthBy CheckFullAccessForSwitch > </Handler> > > > hope that helps > > regards > > Hugh > > > >> On 7 Sep 2016, at 23:28, daniel.herrm...@zv.fraunhofer.de wrote: >> >> Hi all, >> >> I want to use Radiator both for RADIUS and for TACACS for Cisco devices, >> including command level authorization. Based on some posts on this list I >> got both the active directory and the TACACS server module up and running, >> but struggle with the configuration of both. >> >> If I understand correctly, the TACACS module simply converts the TACACS >> authentication requests to radius requests and passes them to Radiator for >> ordinary execution. Authorization requests are handled within the TACACS >> module. >> >> My configuration currently looks as follows: >> >> --- begin --- >> <AuthBy LDAP2> >> # Define DC to connect to >> Host dc-b.ad.xxxxx.com >> >> # Identifier to use this AuthBy Clause later >> Identifier AuthByAD >> >> # Administrative user used to perform LDAP queries >> AuthDN >> cn=Administrator,cn=Users,DC=ad,DC=xxxxx,DC=xxxxxxx,DC=de >> AuthPassword xxxxxxxx >> >> # Where to search for users >> BaseDN OU= User,DC=ad,DC=xxx,DC=xxxxxxx,DC=de >> ServerChecksPassword >> >> # Add Check for group membership >> AuthAttrDef memberOf, ADGroup, check >> >> # Reply should include the group names for further processing >> AuthAttrDef memberOf, ADGroups, reply >> >> # There will be no default User >> NoDefault >> >> # LDAP attribute to check the UserName on >> UsernameAttr sAMAccountName >> </AuthBy> >> >> <ServerTACACSPLUS> >> Port 49 >> AddToRequest NAS-Identifier=TACACS >> GroupMemberAttr tacacsgroup >> >> AuthorizeGroup network_ro deny service=shell cmd=show >> cmd-arh=tech-support >> AuthorizeGroup network_ro permit service=shell cmd=show cmd-arg=.* >> AuthorizeGroup network_ro deny .* >> >> # This is for authorized users for full access. Place in lvl 15 >> immediately, no restrictions apply >> AuthorizeGroup full_access permit service=shell cmd\* {priv-lvl=15} >> AuthorizeGroup full_access permit .* >> >> # Default deny to prevent accidents when something is misconfigured >> AuthorizeGroup DEFAULT deny .* >> >> </ServerTACACSPLUS> >> >> # Include client definition >> include %D/radius-clients.cfg >> # Include Active Directory AuthBy Handler >> include %D/authby-ad.cfg >> # Include configuration for the built-in TACACS server >> include %D/tacacs.cfg >> >> # TACACS Handler >> <Handler NAS-Identifier=TACACS> >> AddToRequest ADGroup="CN=netadmin,C=ad,DC=xxxx,DC=xxxxxxxx,DC=de" >> AuthBy AuthByAD >> >> # Try read-only access >> # AddToRequest >> ADGroup="CN=netadmin-readonly,C=ad,DC=xxxx,DC=xxxxxxx,DC=de" >> # AuthBy AuthByAD >> </Handler> >> --- end --- >> >> My problem now is how to tie both clues together in the handler. Ideally I >> would also like to distinguish based on the TACACS client which is asking. >> If it is a firewall (IPs known), then use command sets full_access_fw and >> firewall_ro based on AD groups. >> >> Basically I need something like this: >> >> - Firewall is TACACS client, and the user is member of group >> netadmin-security, return request with tacacsgroup=full_access_fw >> - Switch is TACACS client, and the user is member of group netadmin, >> return request with tacacsgroup=full_access >> - Firewall is TACACS client, and the user is member of group >> netadmin-security-ro, return request with tacacsgroup=firewall_ro >> - Switch is TACACS client, and the user is member of group netadmin-ro, >> return request with tacacsgroup=network_ro >> >> How would I do this mapping? >> >> Many thanks and best regards >> Daniel >> >> >> _______________________________________________ >> radiator mailing list >> radiator@open.com.au >> http://www.open.com.au/mailman/listinfo/radiator > > -- > > Hugh Irvine > h...@open.com.au > > Radiator: the most portable, flexible and configurable RADIUS server > anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, > Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, > TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, > DIAMETER, SIM, etc. > Full source on Unix, Linux, Windows, MacOSX, Solaris, VMS, NetWare etc. > > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"* 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