Fortinet-Group-Name for whole user group on 5.1.1

[rojekj]

Hi all,

I'm trying to configure FortiAuthenticator 5.1.1 with Fortigate 5.6.2. I have many groups on FortiAuthenticator and I want to use them on Fortigate for SSl VPN. Every user group should have different policies. That is why FAC needs to pass information about user group to FG.

On FG i have RADIUS configured, in every user group I have "Remote Groups" with "Group Name" configured.

On FAC:

When I add "Fortinet-Group-Name" RADIUS Attribute in user configuration IT WORKS.

When I add "Fortinet-Group-Name" RADIUS Attribute in group configuration IT DOESN'T WORK. The attribute is not being passed to FG.

Is this normal? Does this mean that I have to manually add this attribute to every user?

Regards,

Jan

[xsilver_FTNT]

Hi,

if you do have FGT group config like:

    edit "RADIUS_FAC_SSL"         set member "FAC_17.49"         config match             edit 1                 set server-name "FAC_17.49"                 set group-name "cn=SSLAllow,ou=people,dc=fortilab,dc=int"             next         end     next

Then it's a very normal and expected behavior.

Fortinet call this behavior "group match" and it works for all outer auth RADIUS/LDAP/TACACS+ a similar way.

For RADIUS protocol, the expected way how FGT get user group membership to compare is mentioned AVP Fortinet-Group-Name.

I wrote a little KB about that few years ago.

http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=FD36464

The only situation where you can actually choose which AVP will carry (and where FGT expect) the group membership is RSSO. But that's slightly different auth from Single Sign-On passive authentications.

Best regards,

Tomas

[rojekj]

xsilver_FTNT,

You wrote on that KB:

Note that some RADIUS servers like FortiAuthenticator can provide RADIUS attributes on per user or per group basis. So either every single user has its own AVP, or user is group member and when authentication happens then the user inherits AVP from the group. The name of the user group on RADIUS server (like in this inherit case) has no direct connection to AVP, so simply by choosing the group is not enough.

So, lets say that I have user "rojekj" on FAC. That user is a member od "vpn_admins" group on FAC. Group "vpn_admins" on FAC has AVP "Fortinet-Group-Name" set to "vpn_admins". FortiGate has "set group-name" configured to "vpn_admins". From Your KB I assume, that this should work.

Well, it doesn't.

I have to set AVP "Fortinet-Group-Name" on user "rojekj", and then it works.

I don't think, that this is by design, and I don't think this is what You wrote in Your KB.

[rojekj]

I also did some debuging of FG.

With AVP set on group:

Forti0001 # diagnose test authserver radius waw60fac0001 pap rojekj ****             

Token Code:******

authenticate 'rojekj' against 'pap' succeeded, server=primary assigned_rad_session_id=618611079 session_timeout=0 secs idle_timeout=0 secs!

With AVP set on user:

Forti0001 # diagnose test authserver radius waw60fac0001 pap rojekj ****

Token Code:******

authenticate 'rojekj' against 'pap' succeeded, server=primary assigned_rad_session_id=618611080 session_timeout=0 secs idle_timeout=0 secs!

Group membership(s) - vpn_admins

[rojekj]

Also tried on FAC 4.3.3. Same thing.

Moreover, I did "diag sniffer packet any 'port 1812' 6 0 a", converted the result to pcap format and viewed it in Wireshark. I cannot see group name to be passed in the response when it is set per group, and it is there when assigned per user.

So this is definitely a problem with FAC, and FG has nothing to do with it.

[xsilver_FTNT]

Hi rojekj,

maybe I have to refine or scratch that part of KB. It was mentioned like a hint.

There are two simple caveats on FortiAuthenticator and Radius Service / Client config.

1-st

I guess that user rojekj is for simplicity sake just local user.

Then you probably have defined realm for "Local users" and used that realm in RADIUS Service/Clients config for your FGT.

Could you share the config screenshot ?

Issue is that with config simple as that you are pointing to local users and every AVP from within the user is going to be passed to FGT. However the simple group membership do not constitute any AVP inheritance.

To inherit group AVPs you have to check the box of Groups Filter on RADIUS Client config and select that group from which you'd like to inherit your AVPs.

2-nd

Your user rojekj is local but User Role was set to Administrator.

This type of local/remote users is supposed to be FortiAuthenticator admin ONLY!

Users in Administrator role DO NOT inherit any AVPs.

But this 2-nd one is most probably not your case as you stated that with AVP inside local user it is working well. So the 1-st one is your issue and solution. And inheritance turned on only after the check box done is the intended design since RADIUS Clients were added AFAIK.

Best regards,

Tomas

[xsilver_FTNT]

Hint:

FortiAuthenticator GUI / System / Network / Packet Capture .. directly captures into Wireshark.

Yes, I know, there are no packet capture filters, still.

[rojekj]

xsilver_FTNT,

You are right, after adding the filter in RADIUS Client configuration, the AVP parameter is properly inherited and passed to FG.

BTW, in my case both users and groups are remote LDAP, but it works anyway.

Thank You very much for Your help :)

Regards,

Jan

[xsilver_FTNT]

Hi Jan,

glad it works for you

.

User origin represented by realm is not that important for the inheritance.

Group origin is also not that important, those could be local or remote groups.

Important is that Filter checkbox and group being selected there. This is the place where RADIUS server pair the group's "RADIUS Attributes" and the AVPs listed to the realm selected in RADIUS Client config on FAC.

So if user do authenticate through the selected realm, or provide no realm indication and therefore fall back into the Default realm, then this paired group's "RADIUS Attributes" will be inherited and attached to the Access-Accept. User specific AVPs should take higher priority in case the AVP is not allowed to appear multiple times in Access-Accept.

Pay attention that mentioned 2-nd caveat with Administrator role user accounts DO still apply.

So if you do mix User and Administrator role users into the same group, then User role users will have AVPs inherited while Administrator role users will NOT inherit anything, regardless being members of the same group.