Radius not giving VLAN after reconnect

[Alan DeKok]

On Sep 26, 2017, at 10:56 AM, Matthew Pulis <mpulis at gmail.com> wrote:
> What I am trying to do is dynamically assigning users to the VLAN based on
> their LDAP OU. So if a user, such as test user abc is in the OU:
> cn=Seminarians,ou=SeminaryOU,dc=seminary,dc=local,  he gets VLAN 11
> dynamically. As explained this works the first time, but the second time
> the authentication is accepted but the Tunnel-Private-Group is not given,
> thus no VLAN is assigned.

  OK... so that is *that* configuration?

> I think here lies the issue, however I am not sure how to go about fixing it.

  Read the debug output to see what search it's doing.  Try that search manually.  Fix the search until it returns what you want.  Configure FreeRADIUS to use that search.

  I gave specific instructions on the process you should use to debug this...

> This is my /etc/freeradius/mods-enabled/eap file:

  I didn't ask for that.

> My sites-enabled/default file:

  I didn't ask for that.  I asked for the configuration which does VLAN assignment.


> if (Ldap-Group == "cn=Teachers,ou=School,dc=seminary,dc=ad") {
> update reply {
> Tunnel-Type = 13,
> Tunnel-Medium-Type = 6,
> Tunnel-Private-Group-ID = "50"
> }

 Which is that.  And only that.

> my inner-tunnel (not sure this is needed but pasting just in case.

  How about reading my messages, and posting the config I asked for?

  Honestly, one BIG reason you're not making progress is that you're doing tons of unnecessary work, and not following basic instructions.

  I asked *specific questions*, and you ignored most of them.  This is not helpful.

> This is the server log of when the client gets assigned correctly to VLAN
> 11.

  That's good.  Did YOU read it to see why the VLAN is being assigned?

> (36)     if (Ldap-Group == "cn=Teachers,ou=School,dc=seminary,dc=ad") {
> (36)     Searching for user in group
> "cn=Teachers,ou=School,dc=seminary,dc=ad"
> rlm_ldap (ldap): Reserved connection (3)
> (36)     EXPAND (cn=%{%{Stripped-User-Name}:-%{User-Name}})
> (36)        --> (cn=abc)
> (36)     Performing search in "ou=SeminaryOU,dc=seminary,dc=local" with
> filter "(cn=abc)", scope "sub"

  That's the useful part.  And after much output, you see:

> (36)     User found in group DN
> "cn=Seminarians,ou=SeminaryOU,dc=seminary,dc=local". Comparison between
> membership: dn, check: dn
> rlm_ldap (ldap): Released connection (6)
> (36)     if (Ldap-Group ==
> "cn=Seminarians,ou=SeminaryOU,dc=seminary,dc=local")  -> TRUE
> (36)     if (Ldap-Group ==
> "cn=Seminarians,ou=SeminaryOU,dc=seminary,dc=local")  {
> (36)       update reply {
> (36)         Tunnel-Type = VLAN
> (36)         Tunnel-Medium-Type = IEEE-802
> (36)         Tunnel-Private-Group-ID = "11"
> (36)       } # update reply = noop
> (36)     } # if (Ldap-Group ==
> "cn=Seminarians,ou=SeminaryOU,dc=seminary,dc=local")  = noop

  Which works.

  Note the "cn=abc" here.  The NON-WORKING auth has:

(97)     EXPAND (cn=%{%{Stripped-User-Name}:-%{User-Name}})
(97)        --> (cn=anonymous)

  Again, while there's a lot of text in the debug output, it tells you EXACTLY what's going on.

  One simple solution is to authenticate with the correct User-Name, instead of "anonymous".

  Another one is to follow Alan Buxey's suggestion.  Assign the VLANs in the inner-tunnel virtual server, in the post-auth section:

post-auth {
	...
	if (LDAP-Group == ....) {
		update outer.session-state {
			Tunnel-Type = VLAN
			Tunnel-Medium-Type = IEEE-802
			Tunnel-Private-Group-ID = "11"	
		}
	}
	...
}

  And read the docs ("man unlang", and examples in inner-tunnel) to see why you do "update outer.session-state".

  And double-check that the "default" virtual server, post-auth section has this in it:

	update {
		&reply: += &session-state:
	}


  And read the comments around that section to see WHY it's necessary.

  In short:

- it's not magic.  But you DO need to understand how things work
- read the docs
- read the debug output
- follow instructions.

  Randomly trying things will just waste your time.  Ignoring instructions from people trying to help you is counter-productive.

  Alan DeKok.