...
We have looked into our dependencies, and found out that our runnable is not affected since the Atlassian runtime system a versions which is out of scope for the vulnerability. Look at Atlassian's FAQ for the incident here about on premises logging in general: : https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html. You may read more about the incident for Atlassian systems in general in Atlassian’s FAQ: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html
...
You could alternatively use the Kantega SSO Snapshots of config (Backup & restore) feature to move your configuration from the old installation to the new. This would also correctly move configuration for Kerberos/SAML/OIDC setups. But configuration for Cloud User Sync will be somewhat more work since these rely on a User directory setup that is not restored. And especially for a SCIM setup, you would have to run the SCIM setup wizard again.
...
Kantega SSO does not affect how application links work by default. However, if you activate API tokens or disable Basic Auth and affect the REST API authentication, then application links could be affected. Because users do not have to authenticate to each application, we recommend using OAuth Impersonation application links.
Why does the user have to log in manually the in manually the first time?
Make sure the Default Group Memberships is set. This setting can be found when editing the user directory. Make sure the group has global logon permissions.
Because of unexpected behavior in confluence when checking if the user has logon permission try configuring "configured required groups".
How can we restrict who should be logged in with Kerberos?
Kantega SSO supports IP blocking/unblocking for when to perform Kerberos. For IP blocking/unblocking to work Kantega SSO needs to see the correct client IP.
Which client IP Kantega SSO sees is shown under "Client IP restrictions".
...
Guide for disabling in Jira:
https://confluence.atlassian.com/adminjiraserver073/configuring-secure-administrator-sessions-861254024.html
In Confluence, please navigate to the address <your_confluence_url>/admin/viewsecurityconfig.action and turn off the value “Secure administrator sessions”.
Guide for disabling in Confluence:
https://confluence.atlassian.com/conf73/configuring-secure-administrator-sessions-991928809.html
User Directories
How are Kerberos users mapped to accounts in User Directories?
...
If you have multiple User Directories, the user will be looked up in the same order as with manual logon.
Our Active Directory has a non-standard User Name Attribute, will that work?
Yes. Kantega SSO will automatically detect that your User Directory has a non-standard User Name Attribute. (Different from sAMAccountName, say "userPrincipalName")
If this is the case, Kantega SSO will first look up the account in AD using the standard sAMAccountName, then map it to the configured User Name Attribute you configured, and finally perform a new search using that name.
Can we use a Crowd User Directory?
Yes. Kantega SSO will search your Crowd User Directory with the standard account name (sAMAccountName)
...
The same SPN (e.g. HTTP/jira.example.com) cannot exist on two users at the same time in Active Directory. The Kerberos test page will detect duplicate SPNs and flag this. To resolve the issue either delete one of the users in Active Directory that has the duplicate SPN. An alternative is to remove the SPN from the user object with this command
setspn -D HTTP/jira.example.com accountname
What could the cause for very slow logins?
User directories can be configured to update group memberships at login, and in some network environments these operations may be very slow. If you experience very slow logins, you should check the settings controlling the update operations. These are found in your user directory configurations.
...
Actually, all user directories are supported. Your users may reside in a combination of Internal User Directory, Active Directory, Crowd, atlassian-user.xml, etc.
...
Yes, adding ?nosaml to the login URL will present the standard username/password screen. This is relevant if you want to log into a local administrator account when automatic redirect to SAML identity provider is enabled.
I have a problem with my IdP setup and have been using the "do not show login page" redirect mode. How can I log in locally to fix this?
By adding ?noautosso noredirect at the login URL, you will avoid being directly sent to you IdP. You could also press the "Cancel" link that is presented very briefly in the upper left of the screen during the automatic redirect.
Can SAML and OIDC login be bypassed?
Yes, adding ?nosso to the login URL will present the standard username/password screen. This is relevant if you want to log into a local administrator account when Automatic redirect to SAML or OIDC identity provider is enabled.
In the same way, when Instant redirect to SAML or OIDC identity provider is enabled, adding ?noredirect to the login URL will present the standard username/password screen.
You find the login URLs for bypassing Instant and Auto redirect in the Redirect rules page for the Identity provider.
Does application links work with Kantega SSO?
...