Welcome to a short video of the latest offering of One Identity Safegaurd Authentication Services.
I'm going to talk briefly about some of the features of Authentication Services, and then walk you through a core use case. Once Authentication Services is deployed, the first step is to join your Unix, Linux, and Mac OS X systems to Active Directory. This is going to enable all of those non-Windows systems to operate as full citizens of Active Directory. This means users will now be able to log onto their non-Windows and Windows systems using the same credentials.
Now that those systems are [? object ?] in Active Directory, we can now extend policy-based management by group policies to them. By doing this, domain policies that enforce critical settings around passwords, for example, will now be enforced on your non-Windows systems as well. With these new systems added to Active Directory, it is very important that administrators have full visibility of this new Unix-centric data. A complete audit trail and change history is provided, and alerts can be configured and sent based on events. For example, when systems are joined to Active Directory, or when users or groups are Unix enabled.
Authentication Services has a web-based centralized management console. This console provides a consolidated view and centralized point of management for local Unix users and groups with the ability to generate reports on activity around those non-Windows systems.
Now let's go into my lab, and walk through a common use case.
For this use case, we're going to add a non-Windows system to Active Directory, Unix enable a user, and then have that user log onto that system using their Active Directory credentials. As you can see here, I've already added a system, but to do that you would simply hit Add Host, and then provide either the FQDN, IP address, or short name, and then hit OK.
The next step in the process is to install the software, or the agent, and then add it to Active Directory. If I double click on this host, we now have some additional information about the host to include local users and groups.
The next step is to Unix enable an active director or user so they can log onto this host. We can do this in a couple of ways. From within the console, I can go to this Active Directory tab, search for my user, which is just ad.user in this use case. Once found, go to the properties of that user, and you'll see a tab called Unix Account. Click on it. Now to Unix enable this account, all I need to do is check this box, and the UID and GID number are generated. I can go and change the UID and GID number if I need to as well as the home directory and the Login Shell.
We also provide a snap in for Active Directory users and computers. If you prefer to use this method, simply search for your user. Once found, go to properties of that user. Here you'll see a new tab called Unix Account. To Unix enable that account, the same as it is in the console, you would simply click this box, and then change any necessary information.
Now that we've added a non-Windows system to Active Directory, and Unix enable an account, let's have that user log onto the system using his AD credentials.
First let's minimize all of this. And now I'm going to bring up my SSH client, which is Putty. I'm going to log onto the system as ad.user with his Active Directory password. As you can see, we're now authenticated. If I run the command opt/quest/bin/klist, you will see that I've been given a Kerberos ticket from the oi.lab domain. This is important if you want to enable single sign on. For example, if you to allow your users to SSH from a Windows to a Linux host, or use any application that is Kerberos aware.
If I were to try to search for the ad.user on this local machine here, it's going to come back empty. And the reason why is because Authentication Services is not a synchronization product. Nothing is being synced with Active Directory. We've added a non-Windows system as a full member of Active Directory, and enabled users to log onto the system using their Windows credential. This goes with one of the main goals of Authentication Services, which is to reduce the number of accounts a user needs. For example, a user no longer needs an account on this non-Windows system, which means administrators no longer need to provision end users on every one of your Linux, Unix, and Mac systems.
This was just one brief example of one of the core features with Authentication Services. I encourage you to go to the Authentication Services section on OneIdentity.com to learn more about features of Authentication Services, and download an evaluation copy.
04:48