Hi Josep

What do you see on the mikrotik log side when you debug radius? it
would help to see if you are getting radius messages from the PF
server.

Also, packetfence.log will also provide some info regarding the user
authentication.

What CAPSMAN version are you using?

Enrique


El mar, 25 jun 2024 a las 13:43, Josep Maria Torné via
PacketFence-users (<packetfence-users@lists.sourceforge.net>)
escribió:
>
> Hi,
>
>
>
> I just deployed Packetfence ZEN in our VMware cluster.
>
> I want to authenticate wifi 802.1x users + device MAC address through 
> Packetfence against our AD, and dynamically assign a VLAN to the user 
> depending on the assigned role.
>
> The wifi controller I’m using is Mikrotik CAPSMAN.
>
>
>
> So far, I’ve managed to add the AD sources for authentication, and configured 
> the CAPSMAN controller on Packetfence.
>
> Now I’m experiencing random problems when a user is trying to connect.
>
> The problems range from no working connection to failure (device gets 
> connected to wifi SSID, but no traffic goes through, or it takes as long as 
> 20-30 seconds to get DHCP answer), to authenticate new users against AD 
> (previously authenticated users seem to work, though).
>
> It works sometimes, but other times it doesn’t.
>
>
>
> Can’t figure out what’s the problem.
>
> I’ve been trying to run some debugging, but also found some problems with the 
> debugging tools mentioned on the manuals.
>
> For example, when trying to test AD credentials, the installation manual 
> (chapter 16.7) says to use:
>
>
>
> #radtest <username> <pass> <server>:18120 12 testing123
>
> (I’m running this command from CLI on the same packetfence server)
>
>
>
> But port 18120 is not open on localhost, so I try with port 1812, that is 
> open.
>
> If I check on log file /usr/local/pf/logs/radius.log, I see the “server is 
> not managed by packetfence”.
>
> Although chapter 16.7 doesn’t mention if it’s necessary to define a new 
> switch, I guess that is indeed necessary to do so.
>
> So I have defined a new switch on Configuation -> Policies and Access Control 
> -> Network Devices -> Switches.
>
> If I try radtest again, now I get a different error message in radius.log: 
> “rejected in post-auth: [username] (from client localhost port 12)”, but 
> still not working.
>
>
>
> I wanted to try radtest because I was seeing the following error while 
> running “raddebug -f /usr/local/pf/var/run/radiusd.sock” when authenticating 
> new users against AD:
>
> “chrooted_mschap: Invalid output from ntlm_auth: expecting 'NT_KEY: ' prefix”
>
>
>
> At this point, AD auth source seems to be properly configured (as it can 
> authenticate some users), but can’t authenticate new users,
>
> I’m stuck and I don’t know what else to try.
>
> I’ll appreciate any suggestion.
>
>
>
> Best regards,
>
>
>
>
>
> --
>
> Josep M. Torné
>
> jm.to...@tsiic.com
>
>
>
>
>
> _______________________________________________
> PacketFence-users mailing list
> PacketFence-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/packetfence-users



--


_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users

Reply via email to