Configuring LDAP Connection on Proget - Linux Container

itops_6398

Hello,

I am running Proget via docker compose using your provided container image. I am looking at what possibilities I have for configuring AD integrated access control for our end users.

I've configured SAML via an Azure Enterprise Application - this is working great, but its a pretty clunky implementation, I had a few questions around SAML and your supported authentication methods as a whole;

In order to assign roles/permissions to users, they must first sign-in via the SSO flow to populate their identity on the Proget side - only them am I able to assign them a role. Ideally you'd support JIT provisioning but I cannot see this anywhere on your docs, is there any method supported for prepopulating SAML ussers?
I don't seem to be able to expose groups to Proget for SAML authentication, in an ideal world I would have a group called "Proget Administrators" in Active directory. I could assign all admin users AD accounts to this group, and then give this group access to login to the Enterprise Application in Azure. Is there any method to do this?
I have the option to configure an LDAP connector (under User Directories / Domains) - I've been able to successfully set this up within my Proget container, and can query users and groups within our AD domain forest. However, I don't seem to be able to do anything else with it? It looks like configuration can only be used with Windows Integrated Authentication, which cannot be setup on your container image as its not Windows-based. Am I missing something here?

Thanks in advance!

atripp

Hi @itops_6398 ,

It sounds like you're on the right track!

From here, you should create a group on your AD domain forest called "ProGet Administrators" (or whatever). Basically what you described in [2].

Then, on the "Tasks" tab, just add the appropriate permission (i.e. admin) for that group. You should see the "ProGet Administrators" appear in the dialog when you type a few characters.

After that, it should work as you'd like.

Behind the scenes, ProGet will attempt to query the user directories you've configured to discover the groups that the user belongs to. On the Testing tool (in the drop down on the security page), you can try to list a particular user's groups if it's not working.

Hope that helps!

Cheers,
Alana

itops_6398

Hi @atripp,

Thanks for your reply, that's worked! I was able to successfully populate the administers role with a group from our AD domain;

However I ran into another issue, the user membership for this group was being resolves as a different user, as the UPN suffix for SAML logons is a routable public domain (user@company.com), whereas the UPN suffix being presented for the user was shown as the domain name (user@company.local) - this meant that the role mappings didn't match up and logins via SAML had no permissions despite the underlying user being a member of the group.

We do present (user@company.com) as the primary UPN suffix within Active Directory, so I think I just need to have a play around with some of the advanced LDAP query settings to get this to match up properly on the proget side - however I have strangely hit another issue.

This was initially working as you can see, I've been able to successfully detect and map the group Proget - Role -- Administrators from AD to the Administer role in Proget in the first screenshot - however I was tweaking some of the advanced LDAP settings and my queries suddenly stopped working. I am now not able to run LDAP queries at all through Proget, I am just getting a principal not found error;

I've fully deleted and re-created the LDAP configuration as it was when it worked 30mins ago, however I just can't get the queries to run anymore. I've confirmed that;

The service account being used for LDAP is unlocked and the password Proget is using is correct
The Proget container can access our domain via FQDN, and LDAP/LDAPS to all routable domain controllers is working correctly

I am a bit stuck on what to try next, do you have any suggestions, or is there any way to enable more verbose logging to see whats going on on the Proget side?

Thanks!

Dan_Woolf

Hi @itops_6398,

Are you still using the defaults for the LDAP Overrides? Unfortunately, AD LDAP queries give very little log output. Right now you are seeing the amount of logging we receive from the AD server. The best way to see more details is to log into your Active Directory server and look in the Windows Event Log to see the errors found in the connection.

On a separate note, when it comes to configuring an Azure Enterprise Application SAML provider to link to your active directory. I have found that changing the nameidentifier claim to use a transformation of ExtractMailPrefix() on the attribute user.userprincipalname will extract the username and typically link well to Active Directory usernames.

Thanks,
Dan

itops_6398

Hey @Dan_Woolf - thanks for your response,

I figured out the issue with the LDAP queries, my LastPass chrome extension was trying to be helpful and it was populating the LDAP Overrides field User name Property Value with the name of my service account, this was causing all LDAP queries to break down after I navigate to the LDAP overrides

This is now fixed and working! Thanks for the details on the SAML claim, I tried the transform as suggested (ExtractMailPrefix(user.userprincipalname)) - however I still couldn't get this to work in our environment, as the AD group synced in Proget via LDAP was expecting usernames in username@company.local format, but the transform stripped the UPN entirely (so the format was just username) which meant that the mapping still didn't match up.

Since our primary UPN suffix is company.com (but the domain is called company.local) I was able to get around this by instead using a join transform to combine the attributes sAMAccountName and DNSDomainName with an @ separator.

The approach seems a little hacky, but it worked :)

Thanks!

Dan_Woolf

Hi @itops_6398,

I'm very happy to hear that you got this working. You typically do not need the UPN because it will be automatically appended when searching for the user in your domain, but it doesn't hurt to be there. There are typically only two scenarios when the UPN is needed; when that username is already in the built-in directory or you have a multi-domain forest setup in Active Directory, then the UPN will tell it specifically where to look.

With all that said, if it is working for you now, then I would leave it as is because SAML and AD/LDAP are difficult enough as it is. We are going to add the transform information to our SAML docs in hopes of helping others later.

Thanks,
Dan