topic LDAP group vs Access role objects in General Topics

LDAP group vs Access role objects

Miroslav_Guoth — Thu, 11 Feb 2021 11:13:45 GMT

Hi Guys,

Could you please point to link where difference between LDAP group and access role is described?
My issue is:
We do have used both in our policy (LDAP & AR) objects.
When user, whose laptop is in domain - meaning internal user with windows - he can match rules setup with access role objects.
When user, whose laptop isn't in domain, but user is still internal and his account is in domain - he can not match rules setup with access role objects, BUT can with LDAP objects
When user is external, but he/she does have account in domain - same behaviour - he can not match rules setup with access role objects, BUT can with LDAP objects

Looks like AR objects are working only with corporate windows laptops.
Is AR "examinating" user differently then LDAP? apparently yes, but do we have exact reason?

We are using R80.30, Take219, Identity Awareness with Identity collector

Thanks a lot for hints

Re: LDAP group vs Access role objects

PhoneBoy — Thu, 11 Feb 2021 16:44:26 GMT

It comes down to how the identity is acquired.

If it is acquired via an Identity Awareness mechanism (AD Query, Identity Collector, etc), an Access Role is the correct thing to use.
LDAP Groups are a more “legacy” mechanism that existed well before Identity Awareness.
Remote Access rules are the most obvious (to me) use of these today, but even Remote Access can be an identity source in Identity Awareness (if you enable it).
There might be a couple other instances where they are still needed/useful that I’m not remembering offhand.

I’d have to see a more precise example of how you’re using it to explain why you’d do that versus use an Access Role.

Re: LDAP group vs Access role objects

Miroslav_Guoth — Mon, 15 Feb 2021 07:20:42 GMT

Thanks a lot, it did make more light 🙂
So If I understand correctly, AR, is working directly with IA mechanism when LDAP is different method which doesn't rely anyhow on IA mechanism

Is there anywhere described how LDAP works on lower level?

My case is, as you described, user connects via Remote Access with certificate authentication. I had rule based only on AR object - it didn't match. AR object matched specific AD group where user belongs to. I created Legacy object, in very same way, to match Any user in that group - rule is being hit now.
So I believe, once DNS is pushed to domain laptop, laptop knows Domain controllers and automatically connect there. Based on that IA knows user's identity.
However if laptop is not in domain (Mac / Linux), Domain cotrollers are not "point of interest" for them?

Re: LDAP group vs Access role objects

PhoneBoy — Mon, 15 Feb 2021 18:44:04 GMT

With Identity Awareness, two things are happening at different times:

Acquire the name/IP association (done with AD Query, Identity Collector, API, Captive Portal, or other methods you configure)
Look up the groups associated with the user (via LDAP) to calculate the Access Roles that apply to that IP

Prior to Identity Awareness, there were different Security Servers (think proxies) and Remote Access that each acquired an identity as part of authenticating the connection.
The LDAP groups were acquired at that point but not shared between each other.

All you need to do is enable Remote Access as an identity source in Identity Awareness.
This is done in the relevant gateway object in the Identity Awareness section.
Then you can use the Access Role to authenticate Remote Access users and not the LDAP group.

Re: LDAP group vs Access role objects

Miroslav_Guoth — Tue, 16 Feb 2021 08:22:33 GMT

I do have that enabled.

The thing is, that IA blade is not turned on when laptop outside of domain connects to GW:
Domain laptop:

Laptop not in domain:

Both users are connected to same vpn on same GW and outputs are from same GW

Re: LDAP group vs Access role objects

PhoneBoy — Tue, 16 Feb 2021 17:08:08 GMT

Is the Mac registered in the domain at all?
There won't be a machine identity without that for sure and likely, something that triggers Kerberos authentication with AD from the machine (you can force with kinit).