Find it...

    Pexip setup with Okta for LDAP

    Follow

    Note:
    Pexip Infinity does neither support or test Okta as LDAP backend, and any non-working scenarios will have to be raised with Okta. Pexip Infinity assumes normal Active Directory LDAP functionality and the Okta LDAP interface does not provide all the same options.

    It is recommended to have a good understanding of LDAP and being able to use ldapsearch for faultfinding.

    The minimum Pexip version installed to try this is Pexip v20.

    Experimenting with Okta can be done for admin authentication, as well as VMR/device/user import.

    Prior to doing the below, your Okta setup needs to be enabled for LDAP Interface.

    At the time of writing this article, as described on https://help.okta.com/en/prod/Content/Topics/Directory/LDAP_Using_the_LDAP_Interface.htm?cshid=ext_LDAP_Using_the_LDAP_Interface this is an Early Access Feature and you would have to reach out to Okta support to enable it. During testing this was done within 3 minutes when calling the Okta support.

    Ensure you have created a group that contains your Pexip Administrators and optionally other groups for i.e. your video support team that should not change server config, but assist users with their calls if needed.

    Be aware that Okta does not support "Complex filters" so (&(cn=bla)(foo=bar)) is not possible, one is only able to search for i.e. (foo=bar). This is something that will need to be worked around by i.e. using OUs etc.

    If you need Pexip support, ensure you are able to recreate your problem towards a standard Active Directory LDAP server, to ensure the issue you are having is not related to the Okta LDAP interface.

     

    Pexip Admin authentication

    Under Administrator Authentication, setup Authenticatoin source as LDAP database and local database (to allow a fallback if there are issues).

    Admin access via LDAP is in general documented here: https://docs.pexip.com/admin/managing_users.htm 

    Key fields

    Replace EXAMPE and EXAMPLE.com with your company name/domain, and obviously replace okta with oktapreview if you are not testing this towards your production deployment. Consult Okta for correct values.

    uid=YOURUSER@EXAMPLE.com,dc=EXAMPLE,dc=okta,dc=com

    LDAP base DN: dc=EXAMPL,dc=okta,dc=com

    Advanced LDAP config:

    LDAP user search DN<leave blank>

    LDAP user filter: (objectclass=person)

    LDAP user search filter: (uid={username})

    LDAP group attributes: memberOf

    LDAP group filter: (objectclass=groupOfUniqueNames)

    LDAP group membership filter: (uniqueMember={userdn})

     

    When you save the above, a green bar will show indicating successful connection, now go to LDAP role mapping and map your Okta group (here PxAdmins) to a role in Pexip (here Read-write).

    Seeing the LDAP group DN list populated with your groups is a good indicatoin Pexip talks to your LDAP server and can list the groups.

    Now try to login with your user@domain.com and your password, assuming you are in this group.

    Follow the normal Pexip documentation for administrator access via LDAP for additional setup.

     

     

    Pexip VMR/device/user sync

    Add LDAP Sync Source similar to the above setup for admin authentication.

    Provisioning via Active Directory via LDAP is in general documented here: https://docs.pexip.com/admin/vmr_syncing.htm. As Okta is not Active Directory, expect that parts of the documentatoin will not be 100% correct.

    Be aware the notice further up on this page regarding complex LDAP filters.

    This means the default LDAP user filter must be set to something like (objectclass=person)

    To exclude users missing data in a certain attribute, as the user filter cannot be used for more than one attribute, you can in the VMR name pattern use an if. I.e. if you only want to create a VMR for users with data in the mobile attribute, set VMR name to:
    {% if mobile %} {{givenName}} .... VMR{% endif %} as this will only create VMRs (name is a required field) for users that have a mobile number.

    A better way of doing this would be in the LDAP user filter setting mobile=* however then no other filters can be applied.

    Example

     

     

     

    Was this article helpful?
    0 out of 0 found this helpful

    Comments