- Auditing Report: Displays a report of all the administrative actions users have performed within Scrutinizer.
- Authentication: Configure general authentication settings, enable or disable different technologies, allow or deny users from different authentication methods and set the order in which methods are attempted.
- Authentication Tokens: These tokens can be used to automate Scrutinizer application logins with user-specific permissions and applicable expiration dates without having to include user name and passwords in the URL.
- LDAP Configuration: Server and connection settings for LDAP integration.
LDAP user authentication process¶
- In the LDAP configuration, administrators provide credentials for an
- LDAP account with permission to see any users they’d like to permit access to.
- This is the account that will be used to search for and authenticate users when they attempt to log in.
- The searchbase defines the group that will be used to search for authorized users. This is a required field.
- The scope of users in that searchbase who are allowed to authenticate can be limited in two ways:
- By specifying one or more Security Groups in the LDAP Configuration
- By specifying individual user account names in Security > Authentication > LDAP
- To configure LDAP integration to use valid certificates, get a PEM encoded version of the Certificate Authority’s Certificate and place it into the /etc/pki/ca-trust/source/anchors/ directory. Provide the full path to the certificate in the “LDAP Server’s CA Certificate File” setting. Set the Certificate Verification to required.
- A user attempts to log in. The system authenticates as the administrative account provided, then checks a searchbase specified by the Scrutinizer administrator for any account matching the username provided. Authentication with the sAMAccountName, UserPrincipalName, or uid attribute is supported.
- If the LDAP server responds with an LDAP_REFERRAL code, Scrutinizer will check the referred server.
- If the Scrutinizer administrator has specified multiple LDAP servers, it will check them all until successfully authentication succeeds or fails.
- Once the user has successfully authenticated for the first time, Scrutinizer checks for any security group they’re a member of which also exists in Scrutinizer with the same usergroup name. If it does, they’re added to the Scrutinizer usergroup automatically.
With LDAP enabled, if you create a usergroup in Scrutinizer that has the same name as a security Group on the LDAP server, when a Scrutinizer user logs in they will automatically be added or removed from the Scrutinizer usergroup to keep Scrutinizer synchronized with the LDAP security groups.
For example, if you have a “Scrutinizer Users” User Group in Scrutinizer and a “Scrutinizer Users” security group in LDAP, when that user logs into Scrutinizer with their LDAP credentials and is a member of the LDAP Security Group “Scrutinizer Users”, that user will automatically be added to the Scrutinizer “Scrutinizer Users” User Group.
If the LDAP user is not a member of the “Scrutinizer Users” security group in LDAP, when that user logs into Scrutinizer, they will be removed from the Scrutinizer “Scrutinizer Users” User Group.
To configure the RADIUS authentication, navigate to the Admin > Security > RADIUS Configuration page and provide the following details:
- RADIUS Server: the hostname or IP address of the RADIUS server;
- RADIUS Timeout: the connection timeout for RADIUS authentication (in seconds);
- Shared Secret: the shared secret for the RADIUS server.
Save the changes and attempt to log in with your RADIUS credentials.
The TACACS + authentication can be set up via the Admin > Security > TACACS+ Configuration page.
- Pre-shared Key: the pre-shared key for the TACACS+ server.
- TACACS+ Port: the TCP port to use when connecting to the TACACS+ server. The default TACACS+ port is TCP 49.
- TACACS+ Server: the hostname or IP address of the TACACS+ server.
- TACACS+ Timeout: the connection timeout for TACACS+ authentication (in seconds).
Save the changes and attempt to log in with your TACACS+ credentials.
To set up the Scrutinizer-Azure ADFS SAML integration, first create the application in Azure.
- After logging in as an administrator, navigate to Azure Active Directory” > “Enterprise Applications.
- Click the New Application button.
- In the Add an Application dialog, choose Non-gallery Application.
- Enter “Scrutinizer” in the form that appears, and click Add.
- Once the application is added, it will redirect a user to its Overview page. In the toolbar on the left, click Single Sign-on.
- Another dialog will appear with authentication options, where “Disabled” is selected by default. Click SAML to continue.
- A form titled “SAML-based sign-on” will appear, having several sections with an “edit” button in the upper-right of each.
- Basic SAML Configuration
- User Attributes and Claims
- Click the claim for http://schemas.microsoft.com/ws/2008/06/identity/claims/groups.
- In the panel that appears, select “Security Groups” for “Which groups associated with the user should be returned in the claim?”
- Change “Source attribute” to “sAMAccountName” (unless the organization uses a different AD naming attribute).
- SAML Signing Certificate
- Copy the App Federation Metadata Url value to be put into Scrutinizer.
- Download the Certificate (Base64) file to be copied to the Scrutinizer server. This document will assume the filename is “azure.cert”
- Set up Scrutinizer
- Copy the Login URL value to be entered into Scrutinizer.
- Copy the Azure AD Identifier value to be copied to the Scrutinizer server in next steps.
This completes the Azure configuration. Users or usergroups have to be assigned to the “Scrutinizer”application in Azure ADFS before they will be able to successfully authenticate to the application.
Log into Scrutinizer as an administrator and follow the steps below.
- Copy the azure.cert to the following directory on the Scrutinizer primary reporter: /home/plixer/scrutinizer/.
- Navigate to the Admin > Security > Single Sign-On page and click Add Server.
- In the modal that appears, enter the following values:
- Name: Enter any unique identifier you prefer (e.g. “Azure ADFS”)
- IdP Identifier URL: Enter the “Azure AD Identifier” URL copied in previous steps
- Entity ID: Enter in the format of https://<scrutinizer_server>/
- Assertion URL: Enter in the format of https://<scrutinizer_server>/fcgi/scrut_fcgi.fcgi?rm=usergroups&action=sso_response
- Audience Value: Enter in the format of https://<scrutinizer_server>/
- Name Attribute: Enter http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name
- Groups Attribute (optional): Enter http://schemas.microsoft.com/ws/2008/06/identity/claims/groups. It will send usergroup names if the company’s IdP is set up to provide them.
- Login URL: Enter the “Login URL” copied in previous steps
- IdP Metadata URL: Enter the “App Federation Metadata URL” link
- IdP Metadata XML (optional): Either the Metadata URL or Metadata XML needs to be entered. Rather than initiating a connection with the IdP to fetch the Metadata URL each time, provide the Metadata XML directly by pasting it into this field.
- IdP Certificate: Enter “/home/plixer/scrutinizer/azure.cert”
- Click Save to save the configuration.
A new row will appear in Scrutinizer’s Single Sign-On Admin view. Log out of the user account. The URL will now end in /login – this is the direct access URL to Scrutinizer’s local and third-party authentication form.
With SSO configured, accessing the root of the server (e.g. https://scrutinizer.mycompany.com/) will automatically redirect to Azure ADFS for authentication. If the user or their group has been assigned access to the “Scrutinizer” application in Azure ADFS, they will be granted access. If the local Scrutinizer admin account is needed, or if other authentication methods are configured (e.g. LDAP or RADIUS), the login form can be accessed directly at https://<scrutinizer_server>/login.
- User Groups: Specifies what a Group login account can access. More details regarding the permissions can be read about under Usergroup Permissions.
Users: Configure login preferences for individual accounts. User Accounts must be a member of one or more User Groups. If no group is selected when a User Account is created, they are placed in the default (e.g. Guest) User Group. Permissions for a User Account are inherited from all the User Groups it is a member of.
User Account Lockout: If a user has a specified amount of failed logins within a defined period of time, that user’s account will be set to ‘locked’ status and will require a user with administrative permissions to unlock it.
These settings are defined in Admin > Settings > System Preferences and include:
Failed Login Max: the maximum failed logins allowed within the Failed Login Window time
Failed Login Window: the number of minutes that the Failed Login Max value is matching against
For example, with these settings:
Failed Login Max = 2
Failed Login Window = 5
Two failed logins within a 5 minute timespan would cause that user account to be locked out.
To unlock the account, an administrative user needs to go to Admin > Security > Users, select the username that is locked out, then click on the Authentication Method tab in the Edit User modal, and change the Authentication Method from ‘locked’ to the appropriate method.