Re: [PacketFence-users] Problem with Users-Sources-AD Rules after upgrading to 5.3.1. Connection type is WIRED_MAC_AUTH. -> Username was NOT defined or unable to match a role - Connection type is EAP. -> Username was defined

[Louis M. <lm...@in...>]

Hi Dennis,

I am not sure I agree with your assessment of the situation.

For one thing, do you need to run pfsetvlan?
Unless you have switches authenticating with port security or link-up/down traps (and you really shouldn’t) then you don’t need it.
Turn it off if all you have is RADIUS authentication.




On Aug 5, 2015, at 11:48 , Dennis Schulmeyer <ds...@me...> wrote:

> [root@testpf vlan]# tail -f /usr/local/pf/logs/packetfence.log
> Aug 05 17:12:42 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] handling radius autz request: from switch_ip => (192.168.6.20), connection_type => WIRED_MAC_AUTH,switch_mac => (00:23:34:a6:0f:06), mac => [70:5a:b6:a7:a5:0d], port => 10504, username => "705ab6a7a50d" (pf::radius::authorize)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: Could not find any IP phones through discovery protocols for ifIndex 10504 (pf::Switch::getPhonesDPAtIfIndex)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Can't find provisioner (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Can't find scan engine (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Connection type is WIRED_MAC_AUTH. Getting role from node_info (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] Username was NOT defined or unable to match a role - returning node based role '' (pf::vlan::getNormalVlan)
> Aug 05 17:12:44 httpd.aaa(2825) WARN: No parameter Vlan found in conf/switches.conf for the switch 192.168.6.20 (pf::Switch::getVlanByName)
> Aug 05 17:12:44 httpd.aaa(2825) WARN: [70:5a:b6:a7:a5:0d] Resolved VLAN for node is not properly defined: Replacing with macDetectionVlan (pf::vlan::fetchVlanForNode)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] PID: "TESTDOMAIN\\dennis.schulmeyer", Status: reg Returned VLAN: 14, Role:  (pf::vlan::fetchVlanForNode)
> Aug 05 17:12:44 httpd.aaa(2825) INFO: [70:5a:b6:a7:a5:0d] (192.168.6.20) Returning ACCEPT with VLAN 14 and role  (pf::Switch::Cisco::Catalyst_2960::returnRadiusAccessAccept)


I am seeing an access-accept here. It returns VLAN 14 which comes from the configuration, in the switches config where you mapped “Mac Detection” to VLAN 14.
Usually what this means is that device is registered (probably because it did so on an EAP connection before) but there is no role for it in the database. 

Look for that device in the “nodes” panel.
I’ll bet you it does not have a role.


> Aug 05 17:31:56 pfsetvlan(1) INFO: nb of items in queue: 1; nb of threads running: 0 (main::startTrapHandlers)
> Aug 05 17:31:56 pfsetvlan(1) INFO: down trap received on 192.168.6.20 ifIndex 10504 (main::handleTrap)
> Aug 05 17:31:56 pfsetvlan(1) INFO: security traps are configured on this switch port. Stopping DOWN trap handling here (main::handleTrap)
> Aug 05 17:31:56 pfsetvlan(1) INFO: finished (main::cleanupAfterThread)
> Aug 05 17:32:05 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] handling radius autz request: from switch_ip => (192.168.6.20), connection_type => Ethernet-EAP,switch_mac => (00:23:34:a6:0f:06), mac => [68:f7:28:d6:9a:04], port => 10504, username => "TESTDOMAIN\\dennis.schulmeyer" (pf::radius::authorize)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: Could not find any IP phones through discovery protocols for ifIndex 10504 (pf::Switch::getPhonesDPAtIfIndex)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: Memory configuration is not valid anymore for key resource::authentication_lookup in local cached_hash (pfconfig::cached::is_valid)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [TESTDOMAIN Users_AdminDept] Found a match (CN=Dennis Schulmeyer,OU=Users,DC=TESTDOMAIN,DC=com) (pf::Authentication::Source::LDAPSource::match_in_subclass)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [TESTDOMAIN Users_AdminDept] Found a match (CN=Dennis Schulmeyer,OU=Users,DC=TESTDOMAIN,DC=com) (pf::Authentication::Source::LDAPSource::match_in_subclass)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [TESTDOMAIN Users_AdminDept] Found a match (CN=Dennis Schulmeyer,OU=Users,DC=TESTDOMAIN,DC=com) (pf::Authentication::Source::LDAPSource::match_in_subclass)
> Aug 05 17:32:06 httpd.aaa(2825) WARN: Trying to compute the unreg date from an undefined value. Stopping processing and making unreg date undefined. (pf::config::dynamic_unreg_date)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] autoregister a node that is already registered, do nothing. (pf::node::node_register)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Can't find provisioner (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Can't find scan engine (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Connection type is EAP. Getting role from node_info (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] Username was defined "TESTDOMAIN\\dennis.schulmeyer" - returning user based role 'VLAN3_Guests' (pf::vlan::getNormalVlan)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] PID: "TESTDOMAIN\\dennis.schulmeyer", Status: reg Returned VLAN: 3, Role: VLAN3_Guests (pf::vlan::fetchVlanForNode)
> Aug 05 17:32:06 httpd.aaa(2825) INFO: [68:f7:28:d6:9a:04] (192.168.6.20) Returning ACCEPT with VLAN 3 and role  (pf::Switch::Cisco::Catalyst_2960::returnRadiusAccessAccept)
> Aug 05 17:32:10 pfsetvlan(4) INFO: nb of items in queue: 1; nb of threads running: 0 (main::startTrapHandlers)
> Aug 05 17:32:10 pfsetvlan(4) INFO: up trap received on 192.168.6.20 ifIndex 10504 (main::handleTrap)
> Aug 05 17:32:10 pfsetvlan(4) INFO: security traps are configured on this switch port. Stopping UP trap handling here (main::handleTrap)
> Aug 05 17:32:10 pfsetvlan(4) INFO: finished (main::cleanupAfterThread)



This , on the opposite, shows a successful authentication for a user. 
The Users_AdminDept rule you have defined for the TESTDOMAIN returns the VLAN3_Guests role. 
If you want the rule to return a different role you have to configure it to do so.

So I am not sure I understand the problem.
Both devices are successfully authenticated. 
They may not get the VLANs you expect but that seems to have to do with the way your sources are configured.

What was the expected behaviour, and how does the above differ from it? 

Regards,
--
Louis Munro
lm...@in...  ::  www.inverse.ca 
+1.514.447.4918 x125  :: +1 (866) 353-6153 x125
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org)