Single sign-on (SSO) is an authentication process which allows users to log in to many different applications with only one set of credentials. They enter their username and password once and are automatically granted access to all programs and services which have been made available to them. After they have authenticated successfully for the first time, the SSO mechanism takes over and handles the authentication to all the other services.
In the first section of this article, “Typical Configuration Options”, I will be using an example to demonstrate the sort of information typically required to perform user authentication against the UCS LDAP. I will be taking you through the necessary configuration steps using the project management system Redmine as an example, as this requests all the typical information.
In the second section, “Types of Search Users”, I will detail the possibilities available to you if it is not possible to search through the UCS LDAP anonymously.
In this article, we will go one step further. After a brief refresher on the topic of password managers in general, we will present a concrete software solution that offers a convenient way to store and manage passwords – so that none of your users have to rely on writing down their access data anywhere in plain text.
Can you imagine conducting an online event solely with self-hosted open-source tools and self-service? Or does that seem impossible to you? This article describes how we did just that by using UCS, Cloudron and BigBlueButton.
It is well-known among IT staff members: the administration tasks (for multiple applications and depending access rights) which apply even with a small amount of users can prove to be very time-consuming. With possible changes of responsibilities or the joining of new staff members, chances are high that uncontrolled growth arises quickly within the IT infrastructure. And not only does this procedure take a lot of time, but it also endangers the security of your system after a while. A common consequence: the administration of users and their access rights becomes a nuisance and tends to get neglected. If not taken on in due time, this problem grows in parallel with the company and will, eventually, cause quite a bit of trouble. To get back in charge as soon as possible, it is recommended to establish a centralized user management in the shape of an Identity Management System.
Quite often, the so-called LDAP directory service (which we have also integrated in UCS) is the core of the identity management system. Meaning „Lightweight Directory Access Protocol“, it rather describes „only“ the protocol itself, even though users tend to adress „the LDAP“, while in fact talking about the LDAP directory service.
In relatively many UCS environments, system administrators have not yet developed consistent processes for detecting, deactivating or deleting inactive user accounts. Over the years, accounts that have not been used for a long time accumulate in the LDAP directory. At Univention, we have developed a new UCS extension on behalf of a customer, which helps to detect such unused accounts. The Lastbind-Overlay-Module and a new Python script detect inactive accounts on LDAP servers, even in large environments with several LDAP instances and distributed system roles.
Establishing a trust relationship means giving users of a domain access to the resources of another domain. In some situations this can extend the options for identity management. In the following example, I will refer to the interaction between Samba in UCS and Microsoft Windows. I will explain in detail how a so-called trust relationship can be configured and what the current state of implementation is.