Masquerading

Numerous attributes are assigned to a user account when it is created, including user and group IDs, the user's home directory, and the login shell. Things get problematic when user data moves from one system to another and the POSIX attributes change in the process. Another issue arises when the environment lacks a central system for user administration, in which case, the account is local to the respective system. As a result, the same user might well be using a different user ID on each system. If users then move to a central system, the account has just a single ID and access to files that belong to an unknown user are lost because the changed user ID cannot be correlated with an account.

The POSIX attributes stored in Active Directory (AD) are usually used to synchronize user accounts from AD on an LDAP server. If you want to try other techniques of providing users access to Linux resources from AD, then you might want to try using different IDs for each account. For example, the FreeIPA identity management framework can assign its own IDs for users from the active directory during configuration of Kerberos cross-realm trusts, which means the framework is not reliant on POSIX attributes that already exist. However, the prospects are not good for those wanting to use particular IDs, because the IDs are arbitrarily selected from a defined range.

ID Views can help. These are available with both FreeIPA and from the client system security services daemon (SSSD). The POSIX attributes for an account are simply overridden with other values, whether you want to change only the user ID or other attributes.

If the ID Views for a system are active, then attributes that were previously saved in a different view will be used when a user logs in. Here, the possibility exists for setting up multiple views for a single user or for a group of users, which is very practical because different attributes can be connected to particular hosts. Even if central management now exists for a user account, the option of using various login IDs remains. The IDs vary according to the system into which the user logs.

FreeIPA has central ID Views, so each system that is part of the FreeIPA domains can use them. When the SSSD service is running on a client, it can query the centrally defined ID Views and implement them on the client system. Without FreeIPA, the SSSD service itself can implement ID Views on the local system, no matter which back-end system is used to get to the user information.

The disadvantage to using local ID Views based on the SSSD service is that the information is kept in the service's cache; therefore, if the cache is deleted, the views previously set up are lost, although you can export the views beforehand and then subsequently import them again if it becomes necessary to delete the cache. This manual approach, though, is quite inconvenient, so the developers are currently working on a more elegant technique for automatically saving the information.

Listing 1 contains a list of all the user attributes that can be overridden by ID Views. The appearance of the attribute ipaSshPubkey stands out immediately. This attribute contains a user SSH key on a FreeIPA system that can be used to log in to the system, which means you can use ID Views to create a particular key for logging in to a particular system. Therefore, it is not necessary to use the same SSH key for all of the systems.

User Information
uid: User Name
uidNumber: User ID
gidNumber: Group ID
loginShell: Login Shell
gecos: GECOS Feld
homeDirectory: Login Shell
ipaSshPubkey: SSH Key
Group Information
cn: Group Name
gidNumber: Group ID

Installing Views

Listing 2 shows an example of how ID Views are installed on a FreeIPA system. First, you need to set up a view with a name and an optional description. The next step involves adding corresponding information to the view that references either a user or a group. In the example given, the user ID for user foobar is changed to 5555. The third command specifies the system on which the view will be used.

# ipa idview-add --desc "My first Test View" testview
# ipa idoverrideuser-add --desc "New UID for foobar" --uid 5555 testview foobar
# ipa idview-apply --hosts gateway.example.com testview

If user foobar now logs in to any system, the user gets the ID that was defined when the user account was set up. However, when the login occurs on the gateway.example.com system, the user ID 5555 should be used. The following example makes this clear:

[root@ipa1 ~]# getent passwd foobar
foobar:*:1225800039:1225800039:Foo Bar:/home/foobar:/bin/bash[root@gateway ~]# getent passwd foobar
foobar:*:5555:1225800039:Foo Bar:/home/foobar:/bin/bash

The idoverridegroup-add option can also be used in place of the idoverrideuser-add option to define the attributes for a new group. The --hostgroups option exists in the event that the new ID view is used for an entire host group. Naturally, the prerequisite is that a corresponding host group has already been set up on FreeIPA.

Local ID Views

You will still be able to define local ID Views with the help of the SSSD service, even when using an alternative identity management system. The following example shows a change of the ID for user foobar to 5555. However, this information is now placed in the cache for the SSSD service instead of on the central FreeIPA system. The sss_overide from the sssd-tools package performs this task:

# sss_override user-add foobar -u 5555
SSSD needs to be restarted for the changes to take effect.

Once the service is restarted, the output from getent passwd should confirm that the user is using a new UID:

# systemctl restart sssd
# getent passwd foobar
foobar:*:5555:1225800039:Foo Bar:/home/foobar:/bin/bash

In the event that additional user information needs to be changed in the future, it is a good idea to remember that the command

sss_override user-add

overrides the entire user entry.

Conclusion

With ID Views from the FreeIPA framework, it is easy to implement the requirement of using various attributes for users and groups. This framework becomes particularly relevant when you are working with users from AD or with systems on which each user uses various IDs. Otherwise, migration to a central identity management solution can become difficult. The SSSD service also offers the sss_override tool, which even makes it possible to modify the information for users and groups to the local system.