Apstra Web UI & FreeIPA integration

First Attempt (the correct one?)

Looking to provide multiple users sane access to Apstra 4.0.0, I found it supports LDAP based directories in the form of “Providers” in the “External Systems” section.

https://www.juniper.net/documentation/us/en/software/apstra/apstra4.0.0/providers.html#creating-ldap-provider

I happily adapted the default configuration to match the FreeIPA schema (tested with Freeipa 4.6.8), I could authenticate users succesfully but authorization failed, not matter what parameter I change to modify the group lookup function.

ParameterValue
Groups Search DNcn=groups,cn=accounts,dc=ipa,dc=mydomain,dc=com
Users Search DNcn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com
Bind DNuid=sys.apstra,cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com
Passwordyou.wish
EncryptionSTARTTLS
Tested “Provider-specific Parameters” – Not working

ParameterValueApstra default?
Username Attribute NameuidYes
User Search Attribute NameuidYes
User First Name Attribute NamegivenNameYes
User Last Name Attribute NamesnYes
User Email Attribute NamemailYes
User Object Class Attribute NameinetOrgPerson*Yes
User Member Attribute NamememberOfYes
Group Name Attribute NamecnYes
Group DN Attribute NameentryDNYes
Group Search Attribute NamecnYes
Group Member Attribute NameentryDNYes
Group Member Mapping Attribute NamememberNo
Group Object Class Attribute Namegroupofnames*No
Tested “Advanced configuration” – Not working

Take into account that “Group Object Class Attribute Name” can take “groupofnames” or “ipausergroup” for this usecase.

Looking at the logs, the attribute for user membership lookup seems to be hardcoded to UID, hence the lookup is:

SRCH base="cn=groups,cn=accounts,dc=ipa,dc=mydomain,dc=com" scope=2 filter="(member=john.doe)" attrs="cn"

When it should be like:

SRCH base="cn=groups,cn=accounts,dc=ipa,dc=mydomain,dc=com" scope=2 filter="(member=uid=john.doe,cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com)" attrs="cn"

The workaround

The correct way to fix this would be to accept a parameter for the user attribute we should use for group membership lookup (DN instead of UID in this case).

As a workaround, I found the “compat” view from FreeIPA could be used to provide another view that’s more inline to what openLDAP would present for example.

The culprit for me is that the compat view:

  • is generated on the fly, it’s not indexed: probably won’t scale if you’re dealing with thousands of users.
  • requires the group to be of class “posixGroup”: because the Apstra groups are expected to be an application only group, it will clutter the view of Unix/Linux sysadmins with irrelevant groups.

In the hope of waiting for a proper fix from Juniper (now owners of Apstra), and given this is a limited environment (in terms of scalability), the workaround seems to be good enough.

As only the group lookup fails, we’ll use the compat view only for the groups.

ParameterValue
Groups Search DNcn=groups,cn=compat,dc=ipa,dc=mydomain,dc=com
Users Search DNcn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com
Bind DNuid=sys.apstra,cn=users,cn=accounts,dc=ipa,dc=mydomain,dc=com
Passwordyou.wish
EncryptionSTARTTLS
Tested “Provider-specific Parameters” – Working workaround

ParameterValueApstra default?
Username Attribute NameuidYes
User Search Attribute NameuidYes
User First Name Attribute NamegivenNameYes
User Last Name Attribute NamesnYes
User Email Attribute NamemailYes
User Object Class Attribute NameinetOrgPersonYes
User Member Attribute NamememberOfYes
Group Name Attribute NamecnYes
Group DN Attribute NameentryDNYes
Group Search Attribute NamecnYes
Group Member Attribute NameentryDNYes
Group Member Mapping Attribute NamememberUidYes
Group Object Class Attribute NameposixGroupYes
Tested “Advanced configuration” – Working workaround

Don’t forget to setup the “Provider Role Mapping” section to get authorization working.

AOS RoleProvide Group
administratorgapstra-administrator
device_ztpgapstra-device_ztp
usergapstra-user
viewergapstra-viewer
Role Mapping setup

Side note

Even though I can get proper authentication & authorization, the “role” user attribute in the profile just shows a gray box for the LDAP backed user. Might be a presentation bug, otherwise the authorization works as expected

Profile for LDAP backed user

Profile for internal admin user