- 09 Feb 2023
- 5 Minutes to read
-
Print
-
DarkLight
-
PDF
LDAP/AD Integration
- Updated on 09 Feb 2023
- 5 Minutes to read
-
Print
-
DarkLight
-
PDF
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:
- Logging into the server that the product is installed on
- Running the
resetadminpassword
command using the service executable - Restarting the service and application pool (if IIS hosted)
- Closing open browser windows or clearing cookies
- 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
This functionality describes functionality starting in ProGet 2022, BuildMaster 2022, and Otter 2022. This is is available as a preview feature in ProGet 6.0.8+.
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
andhunter42
- 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
This describes the behavior of ProGet 6.0, BuildMaster 7.0, Otter 3.0, and earlier.
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.