MOHAMEDFHAFAH

Single sign-on means the application (the service provider, SP) trusts an identity provider (IdP) to authenticate users, so it never handles their passwords. Entra ID can play the IdP for GitLab with either SAML 2.0 or OpenID Connect (OIDC).

How they differ

• SAML 2.0 exchanges signed XML assertions through the browser. It is long established in enterprise applications, and it is what I used in my team project.
• OIDC is a layer on top of OAuth 2.0: the application receives a signed ID token (a JWT) and calls standard endpoints. It is lighter to implement and fits modern web, mobile and single-page applications.

What you actually maintain

• SAML: signing certificates (and their rotation), the NameID format, the attribute and group mapping.
• OIDC: client secrets (and their rotation), exact redirect URIs, the scopes and claims that are requested.

Provisioning is a separate question

SSO only handles the sign-in. Creating, updating and deactivating accounts is the job of SCIM. In my project the pair was SAML for sign-in and SCIM for the joiner-mover-leaver lifecycle. Which provisioning and group-sync features are available depends on the GitLab edition, so check the documentation of the edition in use.

Common causes of failure

• An expired certificate or secret, or one rotated on one side only.
• A NameID or email attribute that does not match the existing account.
• Clock skew between the two systems, which invalidates short-lived assertions.
• Groups that are mapped in one direction only, so roles drift.

How I would choose

OIDC for a new application or a modern stack; SAML when the application only supports it or when a SAML federation already exists. In both cases, enforce SSO, remove local passwords where possible, and deprovision through SCIM so that leavers lose access.

In Active Directory, any authenticated user can ask the domain controller for a Kerberos service ticket for an account that has a service principal name (SPN). Part of that ticket is encrypted with a key derived from the service account's password. An attacker takes the ticket away and tries to guess the password offline, without further traffic to the domain.

Why it works

• No special privilege is needed to request the ticket.
• Service accounts often have weak, old or never-rotated passwords.
• Tickets encrypted with RC4 (encryption type 0x17) are the cheapest to crack.

Detection

• Windows event 4769 (a Kerberos service ticket was requested), filtered on RC4 encryption type 0x17.
• One account requesting tickets for many different SPNs in a short time.
• A decoy account with an SPN that no real service uses: any request for it is suspicious.

Hardening

• Group managed service accounts (gMSA): long random passwords managed and rotated by Active Directory.
• Long random passwords on the service accounts that cannot be gMSA.
• Allow AES only and disable RC4 for Kerberos where applications permit it.
• No SPN on privileged accounts, and a tiered administration model, so that a cracked service account does not lead to domain admin.

Its close cousin

AS-REP roasting targets accounts that have Kerberos pre-authentication disabled: the attacker only needs the account name to request material to crack, without knowing any password. The fix is to find and re-enable pre-authentication on those accounts. In my lab I exercised both attacks, then remediated with a tiered administration model and group policy objects.

ISO/IEC 27002:2022 groups technology controls in chapter 8. Two of them matter most for a Git platform such as GitLab: 8.2 (privileged access rights) and 8.4 (access to source code).

8.2, privileged access rights

• Keep the number of administrators and owners small, and give each a separate administration account.
• Grant elevated rights for a limited time and for a reason, then remove them (the idea behind privileged access management).
• Review privileged accounts on a schedule, and log what they do.

8.4, access to source code

• Give repository access by role and by need, through groups rather than by individual.
• Protect the main branches and require review before a merge.
• Govern the tokens and service accounts that read or write code: they are identities too.
• Enforce SSO and deprovision automatically, so that leaving the organisation removes access.

What I did with it

In my team project, the access policy for a MedTech SME was aligned with these two controls, together with HDS and GDPR requirements. PAM was covered at the level of the policy and a comparison of vendors (Entra ID, Okta, BeyondTrust, CyberArk), not through a deployment.