Managing user identities in a network

Photo by Brett Jordan on Unsplash

We have already discussed a bit why your identity is important for an operating system: files have owners and permissions. When you are not part of a network, this identity is resolved easy: the operating system will ask to create a user and set a password for it during or after installation. The step is so streamlined that nobody really thinks about it. This is what establishes your identity for your computer: the local identity.

When you are part of a network, as we saw in the previous article, especially when dealing with network file shares, you may want to retain somehow the rights of your user across the network. But the network has no idea about your local user and its password. How could we fix that? When you enter your credentials at the login prompt, your device could simply ask around in the network if anybody ever heard of you. If someone responds, you are granted access. And to make “asking around” more efficient, we could store all the credentials in the network on a designated computer: the network’s identity server.

There are two parts to this of course. The server needs to run special services that use appropriate protocols that validate given credentials, and the clients need to know to defer credentials validation to this server. So all participants in the network need to be configured to authenticate using the designated identity server. This makes for a lot of configuration to take place and we will see throughout this series exactly how to do it.

There has to be a standard: LDAP

Photo by Edho Pratama on Unsplash

Storing identities on a server and validating credentials from clients over the network has all been standardized in the Lightweight Directory Access Protocol, or simply LDAP. I am no historian and I certainly don’t have the gift to explain how we came up with this standard, but there are plenty resources out there that cover all the technical details. What we need to go forward though is this:

• each entry in a directory (or identity) server has a “distinguished name”, or dnand it looks like this: dn: cn=User Name, dc=yourdomain, dc=com. Note the dc=yourdomain, dc=com: this is how you identify the domain yourdomain.com. So this entry defines the user User Name on the yourdomain.com domain
• the dc you saw above is called a “domain component”. Note that yourdomain.com has two domain components: yourdomain and com
• a directory entry will have an “object class” that looks like this: objectClass: person. The class identifies the entry type and there can be many entry types: users, computers, printers, network shares and so on. There is a schema for each type and you can import custom schemas in your directory server that can define anything you want

LDAP supports the typical add, delete and modify commands and their bodies contains text that looks like this (and is called LDIF):

dn: uid=user1,ou=people,dc=yourdomain,dc=com
changetype: add
objectClass:top
objectClass:person
uid: user1
sn: Last Name
cn: First Name
userPassword: some encrypted password 

As hinted earlier, LDAP can store all kinds of information. In practice though the traditional items are user identities, groups and their users, sudo rights and automount information. We’ll talk about each category in the next articles.

There have to be implementations: Active Directory, OpenLDAP and FreeIPA

Photo by Clem Onojeghuo on Unsplash

Now that we saw the standard and we got a glimpse of how it works, we should know that there are many implementations of this standard. A very well known implementation is Microsoft’s Active Directory. What is not so well known is that Active Directory was not the first LDAP implementation. But I will refrain from grumpiness and will move over.

Beside Active Directory which is the only implementation for Windows devices, there are two alternatives for Linux that can also integrate well with Active Directory: OpenLDAP and FreeIPA. The following articles will cover the configuration of these directory services on a typical Ubuntu Server. The items will become links as I write the articles:

1. Building an identity server with OpenLDAP
2. Adding sudoers to the OpenLDAP server
3. Adding automounts to the OpenLDAP server
4. Building an identity server with FreeIPA
5. Adding users and services to FreeIPA

Cloud identity providers

Photo by Firmbee.com on Unsplash

Of course there had to be a way for the cloud to sneak in this story. And the way big cloud corporations sneaked in was not always nice and clean. For example there is no way to have a local user on your phone. You log in to your Android phone using a Google cloud account and on your Apple phone using an Apple cloud account.

Then there is the login Facebook offers for accessing third party web sites. You saw the Facebook Login button on many sites. You probably use it too because you feel it’s convenient. In this way, Facebook becomes an identity server for all the websites that use Facebook Login. Same for Google and Apple.

These days for example Microsoft is turning to full online accounts by letting the users log in to their Windows machines using a Microsoft Outlook account. And of course there is the actual Microsoft Active Directory offering for the cloud that you can setup in Microsoft Azure. Also, Microsoft Office 365 has enterprise login. And many many others.

Weather cloud identity is safe, useful, good or bad: this is certainly not the time to talk about it. I wrote about some arguments against having stuff in the cloud before, I wrote about reclaiming your content from the cloud and certainly I advocate for keeping your home identity in your local home network and I write this blog hoping that others will see the same. And also to be of help for those who see the same.

Welcome to a new series about establishing the identity of your home network users. When your user identities reside in a home server, user management gets extremely easy because they can login with their credentials on any device in the network. You can add more users by simply running some operations on the identity server. But of course, this also comes with added complexity for the network and for the home server.

As a warning, I have to say from the start: you don’t need to do this. If your home users are skilled and they want to manage their own devices, they try different Linux distributions from time to time or they just want to have things their way, don’t impose a centralized authentication protocol because it will just be a burden. Otherwise, if you feel up for the challenge, I hope this series will be of help. See you next time!