[RADIATOR] AuthBy FILE + IfNotExist and/or maintaining Access response

[Nathan Anderson]

Robert Fisher wrote:

> We have a similiar case in that we have to treat certain clients
> differently from others -- so we end
> up with different Handler clauses using the Client-Identifier to group
> them into the appropriate
> responses.   And since you can either use IdenticalClients keyword or
> map several entries from
> a ClientListSQL entry to the same identifier -- it allows the
> flexibility of dealing with devices as a
> group or type in the event equipment is added or replaced down the
> line. 

Hey Robert,

Thanks for the response!  I'm not sure whether or not you intended for your message to not go to the list, but it seems like this is a good jumping off point for further discussion on this topic, so I hope you won't mind if I send my reply to the list.

I had thought about using a different Handler for the Dell switches, but not with Client-Identifier...I would prefer NOT to have to manually maintain a list of different clients.  If I can identify a client type in real-time without having to build a static client mapping table that I have to update when equipment gets changed, that's the way it should be done.  And as I demonstrated in my original post, I can identify the client...now I just need to know how to get Radiator to do what I want based on that.

The problem is that using a Handler still doesn't solve my basic problem of being able to express the problem in the Radiator config in a way that works.  To wit:

<Handler cisco-avpair="shell:priv-lvl=1">
	AuthByPolicy ContinueUntilAccept

	<AuthBy FILE>
		Filename RADIUS-DELLFIX
	</AuthBy>

	AuthBy			Staff-Admin   # LDAP
	AuthBy			Staff-Normal  # LDAP
	AuthBy			Global-Users  # FILE
</Handler>

This version still has the same problem with the ordering of the multiple Service-Type attributes inside the reply packet as I currently have, essentially because it is unchanged.  Okay, so let's try reordering some things, now that we at least KNOW it's a Dell switch going into it:

<Handler cisco-avpair="shell:priv-lvl=1">
	AuthByPolicy ContinueUntilAccept

	<AuthBy FILE>
		Filename RADIUS-DELLFIX
	</AuthBy>

	AuthBy			Staff-Admin   # LDAP
	AuthBy			Staff-Normal  # LDAP
	StripFromReply		Service-Type
	AuthBy			Global-Users  # FILE
</Handler>

Well, crap: that won't work.  It takes care of the duplicate Service-Type attributes in the reply, but it does so by favoring the LAST one used, from the AuthBy FILE (if the match is in there), which does me no good since I may as well not have included the DELLFIX AuthBy FILE at the beginning if that's the case.  If the user was matched against once of the LDAPs instead of the Global-Users FILE, then the situation is even worse since the reply will go to the client without ANY Service-Type attribute at all.

<Handler cisco-avpair="shell:priv-lvl=1">
	AuthByPolicy ContinueWhileAccept  # or ContinueUntilReject

	AuthBy			Staff-Admin   # LDAP
	AuthBy			Staff-Normal  # LDAP
	AuthBy			Global-Users  # FILE

	StripFromReply		Service-Type
	<AuthBy FILE>
		Filename RADIUS-DELLFIX
	</AuthBy>
</Handler>

That obviously won't work because the user is only going to exist in one of those three AuthBys, so we will ALWAYS see a Reject come back.  I can't use ContinueUntilAccept, though, because then Radiator will bail out after it gets a positive hit from one of the AuthBys, which means that it will never reach DELLFIX.

What if I change DELLFIX's DEFAULT user to Auth-Type=Accept, and then use AuthByPolicy Continue?  Well, that won't work...the user will get matched against all three AuthBys, and before it hits DELLFIX it might be EITHER an Accept OR a Reject depending on whether the user is matched against the last AuthBy or not.  But regardless of that, DELLFIX's DEFAULT will then give *everybody* an Accept in the end, even if there were 0 matches in the previous 3 AuthBys!  Not good.

It seems like this should be a simple problem with a simple solution, but I cannot seem to come up with a way that allows me to address this problem using the current tools from Radiator that are at my disposa (at least, not that I can see).

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com