MSM765 + WINDOWS AD

[Pavel Chelisant]

Hi all!
i successfully joined controller to domain, and its status points AS joined. But when im trying to auth via client in logs shows that LOGIN OK, but then i receive ACCESS REJECT.
HERE some log i got

Mar 5 16:10:37 debug radiusd I:rlm_eap_mschapv2: Issuing Challenge
Mar 5 16:10:37 debug iprulesmgr Received RADIUS Packet (Length:'159',Code:'Access-Challenge',Id:'134') from RADIUS Server (Ip:'127.0.0.1',Port:'27910') for User (nas-port:'666',username:'pchelisant').
Mar 5 16:10:37 debug iprulesmgr Sending RADIUS Access Challenge (id='237') to RADIUS Client (ip-address='169.254.0.4',port='32772').
Mar 5 16:10:37 debug iprulesmgr Received RADIUS Access Request (id='27') for user (calling-station-id='00-13-CE-D7-CC-D7',virtual-ap-index='2') from IEEE802dot1x RADIUS Client (ip-address='169.254.0.4',port='32772',called-station-id='00-0F-61-7F-BB-F0:ML_ES').
Mar 5 16:10:37 debug iprulesmgr Sending RADIUS Packet (Length:'374',Code:'Access-Request',Id:'161') to RADIUS Server (Ip:'127.0.0.1',Port:'1645') for User (nas-port:'666',username:'pchelisant').
Mar 5 16:10:37 debug radiusd E:internal authorization attributes are missing.
Mar 5 16:10:37 debug radiusd Last message repeated 1 times
Mar 5 16:10:37 debug iprulesmgr Received RADIUS Packet (Length:'174',Code:'Access-Challenge',Id:'161') from RADIUS Server (Ip:'127.0.0.1',Port:'27910') for User (nas-port:'666',username:'pchelisant').
Mar 5 16:10:37 debug iprulesmgr Sending RADIUS Access Challenge (id='27') to RADIUS Client (ip-address='169.254.0.4',port='32772').
Mar 5 16:10:37 debug iprulesmgr Received RADIUS Access Request (id='98') for user (calling-station-id='00-13-CE-D7-CC-D7',virtual-ap-index='2') from IEEE802dot1x RADIUS Client (ip-address='169.254.0.4',port='32772',called-station-id='00-0F-61-7F-BB-F0:ML_ES').
Mar 5 16:10:37 debug iprulesmgr Sending RADIUS Packet (Length:'311',Code:'Access-Request',Id:'173') to RADIUS Server (Ip:'127.0.0.1',Port:'1645') for User (nas-port:'666',username:'pchelisant').
Mar 5 16:10:37 debug radiusd E:internal authorization attributes are missing.
Mar 5 16:10:37 debug radiusd Last message repeated 1 times
Mar 5 16:10:37 debug radiusd A:Login OK: [pchelisant] (from client localhost port 666 cli 00-13-CE-D7-CC-D7)
Mar 5 16:10:37 debug iprulesmgr Received RADIUS Packet (Length:'138',Code:'Access-Challenge',Id:'173') from RADIUS Server (Ip:'127.0.0.1',Port:'27910') for User (nas-port:'666',username:'pchelisant').
Mar 5 16:10:37 debug iprulesmgr Sending RADIUS Access Challenge (id='98') to RADIUS Client (ip-address='169.254.0.4',port='32772').
Mar 5 16:10:37 debug iprulesmgr Received RADIUS Access Request (id='82') for user (calling-station-id='00-13-CE-D7-CC-D7',virtual-ap-index='2') from IEEE802dot1x RADIUS Client (ip-address='169.254.0.4',port='32772',called-station-id='00-0F-61-7F-BB-F0:ML_ES').
Mar 5 16:10:37 debug iprulesmgr Sending RADIUS Packet (Length:'320',Code:'Access-Request',Id:'149') to RADIUS Server (Ip:'127.0.0.1',Port:'1645') for User (nas-port:'666',username:'pchelisant').
Mar 5 16:10:37 debug radiusd E:internal authorization attributes are missing.
Mar 5 16:10:37 debug radiusd A:Login OK: [pchelisant] (from client localhost port 666 cli 00-13-CE-D7-CC-D7)
Mar 5 16:10:37 debug iprulesmgr Received RADIUS Packet (Length:'214',Code:'Access-Accept',Id:'149') from RADIUS Server (Ip:'127.0.0.1',Port:'27910') for User (nas-port:'666',username:'pchelisant').
Mar 5 16:10:37 debug iprulesmgr Sending RADIUS Access Reject (id='82') to RADIUS Client (ip-address='169.254.0.4',port='32772').

[Pavel Chelisant]

Who will point me to the problem?
Thank you!

[Trevor Commulynx]

You have Radius Rejects, are you sure you have the VSC set to use AD for Auth?

[Pavel Chelisant]

sure

[Fred!]

Can you provide a screen capture of the AD page? Did you activated any Active Directory group attributes profiles?

[Pavel Chelisant]

See attach

[Pavel Chelisant]

Regarding attributes, the only thing i did is created groups named as my OU domain containers. But seems something is not correct, because LOGIN OK i receive only when default NON AC group is activated....

[Fred!]

So that I clearly understand: I can see that you have created a couple of groups that are not access controlled. Your active directory setup seems OK so far.

However, I need to understand if the user 'pchelisant' from the traces above is connecting on a VSC that has access control enabled or not? Can you confirm the setings in your VSC?

[Pavel Chelisant]

The user PCHELISANT is a domain user. And only 1 default AD group is activated = NON AC Controlled. This is shows in the pic. So user is not Access controlled

[Fred!]

I can see that you only have configured non-access controlled as an AD group from your screen capture, but my question was is the VSC/SSID that you connect to really non-access controlled?

The reason why I'm asking is that I suspect it is access-controlled from the traces that you have in your first post.

Could you please do a screen capture of the VSC page (just the top of the page, not the entire page) so that we can verify?

[Pavel Chelisant]

HI! here is the sreenshot

[Fred!]

OK, I see that I was wrong. Everything seems fine with your VSC and AD setup. Well then we will have to go deeper in order to figure out what's going on. Can you do the following:

Can you start the extra Radius/AD debug in the Tools > System Tools, put in place an external/remote syslog to make sure all the info is captured, as well as starting a trace on 127.0.0.1 radius port 1645 (the MSM controller loopback interface and internal RADIUS server).

And post/attach the captured remote syslog, and trace as well as providing the SW version number that you are using so that we can have more details around what's going on within the controller?

[Pavel Chelisant]

Here the log file

[Pavel Chelisant]

Generally i dont understand to get it worked one day. Theoretically its all clear for me. But..
Just a few words in addition:
In official HP Installation giude said that controller which joined to AD "retrieves the names of all the active directory groups of which the user is a member". Prior said that we should define group attributes with the same name that OU containers in Domain controller. My user belongs to OU = IT (and this attribute defined). In all ways controller should pass through this to find out if user belongs to this group. Forthemore if i deactivate the DEFAULT GROUP the user becomes unknown (invalid), but it found in AD (the attached log this shows). If I turn back on i receive "A:Login OK" but then access reject......
In addition i liked "Egress VLAN" feature in the attributes configration because my users are in different OU and i want to make this OU users connected to the network with their "wired" dhcp range and existing VLAN..
But how to get it worked....

[Fred!]

My assessment from the log and the screen captures is that the system does not find the proper group that matches your user and reject the authentication because it cannot find the attributes to be applied.

The name of the groups that you configure in the Authentication > Active Directory page MUST absolutely match what is returned by your Active Directory server.

It seems from the more detailed log that your Active Directory server returns groups like "GIT", "(MX) Administrators", (MX) IT Group", "DIAL IN", "(MX) All Employees", "(MX) TO", "(MX) HD" and "GRASIT" for your user.

The issue is that none of these group names correspond to a profile in your MSM Active Directory page, which defines groups like "it", "departments", and "users". Try renaming the "it" group on the MSM controller to "GIT" or whatever name that correspond to a real Active Directory group returned by your server to see if that works.

I strongly suspect this is why the system cannot match the user attributes and refuses the authentication.

Again, to match the user attributes, the MSM controller much have an EXACT match between what's returned from the Active Directory server and what has been configured as group locally on the MSM controller.

[Pavel Chelisant]

Just only today morning i parsed log file one more time and made as you advised. And its all WORKED. The documentation made me a bit confused because it said (as i could understand) there that groups should match the OU containers... I consulted with my DOAMIN admin and he provided me the OU names without "G". Nevertheless thank you much for your help.
One more thing, egress vlan directly from GROUP ATTRIBUTE page doesnt work, only works if i assign an account profile and put VLAN there...
Is it ok?

[Fred!]

Not supposed to happen. When you click on the checkbox next to Egress VLAN in the group attribute and specify a VLAN it should override any potential assignment in the account profile.

Actually a pretty good feature of the product is to be able to "see" the result in the effective attributes. I have attached an example.

So I would say make sure the checkbox is on next to the VLAN that you don't have an account listed and that the result windows shows the actual VLAN that will be assigned.

If you have all that, then it should work and the VLAN should get assigned.