LDAP/AD Integration

Inedo products come with their own built-in users and groups, but they can also integrate with an external directory service like Active Directory and other LDAP-based services. This allows you to use the organization's existing users, logins, and groups to secure the product and define the tasks users are permitted to do.

Administrators can also enable Single-Sign On (i.e. Windows Integrated Authentication) so that end-users don't have to enter their username/password to use the product.

Built-in Users & Groups

When an Inedo product is first installed, a default administrator username/password (Admin/Admin) will be created. You should obviously change this password or delete this user once configured the product. You can also disable Built-in User Sign-on completely, which means users will only be able to log-in using their external (i.e. Active Directory/LDAP) credentials.

Restoring Default Admin Account

If you ever get "locked out" of an Inedo product, either due to misconfiguration or a lost password, you can restore the default Admin/Admin account and reenable Built-in User Sign-on. This involves:

1. Logging into the server that the product is installed on
2. Running the resetadminpassword command using the service executable
3. Restarting the service and application pool (if IIS hosted)
4. Closing open browser windows or clearing cookies
5. Navigate to root url of product (e.g. https://myproget.company.local/)

HOWTO: Restore ProGet Default Admin Account

This Script will reset the account on Windows, so you can just copy/paste as needed.

"%progamfiles%\ProGet\Service\ProGet.Service.exe resetadminpassword
try { Restart-WebAppPool ProGetAppPool } 
catch { Restart-Service INEDOPROGETWEBSVC } 

Note that the try/catch statement is there to make this work for both IIS Hosted and Integrated Web Server.

Built-in Users/Groups in the Database

The users, logins, and groups you create in the product are called "Built-in Users & Groups", and are stored in the product's database (specifically, the Users, Groups, and UserGroups tables). Note that the passwords themselves are not directly stored; instead, passwords are cryptographically hashed/salted (see OWASP's Password Storage Guidelines).

Importing and Exporting Security Configuration

You can import or export users/groups and task/permissions as JSON documents. This may be helpful for diagnostic purposes, bulk-editing, or migrating instances.

• To import or export users/groups, navigate to Admin > Manage Security > Built-In Users & Groups, then select either "Export Users & Groups" or "Import Users & Groups".

• For Tasks / Permissions, navigate to Admin > Manage Security > Tasks / Permissions, then select either "Export Tasks" or "Import Tasks".

This functionality is available starting In ProGet 2022, BuildMaster 2022, and Otter 2022.

Domains & Active Directory/LDAP Integration

Inedo products use a "User Directory" to validate logins and find usernames and user groups in an external directory service. While it's possible to create a custom user directory component using the Inedo.SDK, nearly all users will have one or more of the LDAP/AD User Directory Types configured.

Configuring Multiple Directories / Domains

You can configure as many user directories as needed, and enable the ones you wish to search. When there are multiple enabled user directories, they will all be used to search users/groups and validate logins.

For example, if mycompany.corp and trusteddomain.corp are both configured, and the Built-in User Sign-on is Enabled:

• If you enter jdoe in a search box then you may see:

  • jdoechestor (from the Built-in Users)
  • jdoeson@mycompany.corp
  • jdoe@trusteddomain.corp
  • jdoedawn@trusteddomain.corp

• When a user logs in with jdoe and hunter42

  • the Built-in Users will be used to validate the login, and if that fails...
  • the mycompany.corp domain will be used, but if that fails...
  • the trusteddomain.corp domain will be used
  • the user will get an "invalid login" error if they all fail

As a result, this behavior may yield to logging of failed logins. The exception to behavior is if the username contains a @ or \ symbol, such as jdoe@mycompany.corp or COMPAN\jdoe. In that case, only the domains that matching that name searched.

Hybrid User Directory

Prior to ProGet 2022, BuildMaster 2022, and Otter 2022, you could create a Hybrid User Directories to approximate this behavior.

Upon upgrade to these versions, the Hybrid User Directory will be removed and the associated directories will be enabled.

Configuration in Earlier Versions

You may only have a single user directory active at a time: either the built-in, or one of the configured LDAP/AD directories) to query.

There are some disadvantages to this approach:

• Easy to get locked-out; if there is a configuration problem, you need to follow the reset-instructions to fix it
• Migrating domains is painful; because each of these directories uses its own sets of privileges, if you want to configure a different user directory, you need to recreate all those privileges

LDAP/AD User Directories Versions

Active Directory installions can be very complex, and its not uncommon for users to integrate our products with a decades-old multi-domain forrest with tens of thousands of users. Over the years, we've learned better ways to integrate with a variety of configurations. However, due to the risk of breaking authentication, we implemented major changes as new new type of user directory.

v1: LDAP or Single Domain Active Directory (Legacy)

This worked for most customers that needed to authenticate using LDAP-only, or integrate with a single domain. It allowed for custom mapping of LDAP property names... which in retrospect was unecessary. All directories we've seen in the field follow the same conventions.

v2: Active Directory Domain Forest (Legacy)

This addressed a major flaw in v1: only a single domain was queried, and for organizations that wanted users from multiple domains to log-in, this was a problem. This user directory removed the unecessary field customization, and searched all domains in an Active Directory Forest instead of performing LDAP queries on a domain.

v3: Active Directory / LDAP (Current)

This was a complete rewrite, and effectively combines the concepts of v1 and v2. It can search multiple domains (each with different credentials), and has several AD-specific features like the ability to search gMSA accounts.

See Advanced Configuration (v3) to learn more.

v4: Active Directory/LDAP (Preview)

This version is based on v3 with added optimizations, advanced LDAP filtering, and is tied to a single domain, simplifying LDAP queries. It also includes a new Microsoft Active Directory Group Search Type for improved performance and customization of LDAP queries, supporting large forests and other LDAP providers.

Task and permission configurations are compatible with both v3 and v4, allowing easy rollback between user directories. This preview feature is included in the InedoCore v2.2.1 extension, available in ProGet v2022.20+ and BuildMaster v2022.0+.

See Advanced Configuration (v4) to learn more.