1z0-821 Oracle Solaris 11 System Administration – System and File Access Part 3

7. Authentication pt. 1

In continuing our discussion on security on solaris Eleven and controlling access to the system and files. Let’s discuss authentication for a few minutes. Now, authentication is simply one step in a process that a user goes through to be able to access the system and the resources. This process, and I’ve broken it down fairly simply for you here. Year consists of identification where we basically present our credentials to the system. In other words, we type in a username and a password and then we’re authenticated. Authenticated means that we are checked against a central database or a file and we make sure that those credentials that we supplied during the identification phase are valid and that we are who we say we are. So we identify ourselves by putting in a username and password. The system authenticates us by saying yes, that’s a valid username and password. And then authorization comes into play when we’re actually given permissions, rights and privileges to perform actions and access resources.

So there’s three separate processes that we go through and this is again a simplified if you are a security person or take a security course, these will be broken out a little bit more, defined in a little bit more detail. But for the purposes of our course that’s pretty much what you need to know about authentication as far as the processes. Now we have several means of authentication available to us that we can use on a solaris Eleven system.

The good old username and password combination that we’re used to using is probably the most common on both local systems and on network systems. We also have several methods of authenticating using multifactor authentication. And when we say multifactor, we’re talking more than one factor. Obviously something you have, something you know, something you are. Those are three factors. And an example would be a smart card and a pin, something you have and something you know, or a token and a pin, or even using biometrics such as using something like the thumbprint and a password for our purposes and on most local solaris Eleven systems we’ll be using username and passwords typically.

Now even with using username and passwords we can authenticate using several different methods. The first could be local on the system itself where the password and username is stored and those use files and we’ll talk about those files in just a moment. Or it could be a network based scheme and a network based scheme could be an authentication server such as an LDAP or a NIST server and we’ll discuss those in a moment as well. The standard method, the local method uses two or three different files that we find on the system. We have an Etsy default password and that’s where your typical security policies are stored. And we also have the Etsy password which is where usernames are stored, and then the Etsy shadow which is where encrypted passwords are stored. And we’ll get a chance to look at all those in the next session coming up. Now, talking about network based authentication, there’s a couple of different ways we can do this. First of all, there’s lightweight directory access protocol and it’s been around a few years and it’s pretty much the standardized way of authenticating to a network these days.

And what LDAP is, it’s a centralized, distributed database of user accounts. You can have it centralized on one system, but replicated to other systems. So if one system happens to be down or unavailable, you can still authenticate. Typically, all systems on the network that are LDAP clients can authenticate to this database and you can log in using the same user credentials from any system that’s connected. Now, Solaris Eleven can be both an LDAP client or an LDAP server. And the LDAP client is actually easy to configure using the LDAP client command. Or if you want to install the packages and configure them to make it an LDAP server, that’s easy to do as well. They’re actually already installed on the system. They just have to be configured and enabled. Then we have the older service, the network information service. This is again, older network based authentication. Unlike LDAP, which uses a hierarchy based scheme, this uses just simple flat files. It’s really local authentication taken to the next level where the local text based files are on one server, it typically offers no security whatsoever.

Again, unlike LDAP, which can use things like Kerberos to encrypt user credentials, and typically nobody uses NIS anymore, it’s pretty much been replaced de facto by LDAP. But some organizations may still use NIS in small environments. So if you have a small workgroup in one building or one room, you typically may not have to worry about setting up a big LDAP service. You can use NIS. Now, NIS is not installed by default on Solaris Eleven, and it’s actually not needed. Again, most people don’t use it, but if you need installed, it’s not too difficult to do. It’s a little bit out of the scope of what we’re talking about now. We just wanted to tell you about it so you’re aware of it and you may or may not get asked a question on the test about it. So just use it for your knowledge. You don’t have to probably worry about configuring it at all, and you probably won’t have to configure LDAP either. But you need to be aware of what it is and how it works. And in another session, we’re actually going to look at the LDAP packages as well as the standard local files that we can see and use for authentication.

8. Authentication pt. 2

During the second part of our discussion on authentication, I’d like to show you in solaris Eleven some of the authentication local files and services that we can use. So we’ll look at the Etsy default password which is basically password policy. We’ll also take a look at Etsy password and Etsy shadow where local user accounts and local passwords are stored and then we’ll take a look at LDAP services. So let’s go ahead and take a look at these. Okay, we’re in solaris Eleven and I went ahead and opened the Etsy default password file with G edit simple text editor in solaris Eleven and what we see here is basically the file, the password file and Etsy default which tells us some policy elements that we can set for local users and accounts and passwords.

Most of this is commented out and these are all the defaults, but you can change these defaults to make your system more secure. Maxweeks and Minweeks sets maximum password life and minimum password life so that passwords expire after a while. Right now there’s not set password length sets the password length to six characters. Now we know that longer and more complex passwords make our system more secure. So you might want to change this. Now name check if it’s set to know makes it so that it will disable login name checking so you wouldn’t have to authenticate to log in. We don’t want to set this typically and right now it’s commented out the little hash mark so it’s not active. We can also set password history. Password history would make it so that we can’t use previously used passwords. Right now it’s not set. As you can see there’s other settings that we can change for the password policy such as password complexity and we can set those different settings to make like minimum numbers of characters, minimum alpha characters, minimum number, minimum uppercase lowercase, and how many digits can even be repeated.

So you can actually set a lot of different complexity values for passwords in this file and that makes it across the board. Now any changes you make will not apply to current user accounts that are set up, they will only apply to new user accounts. So if you want to do it for everyone, you’d have to change this and then force everyone to change their password. You can also use dictionary lists that could be set up so that they can’t use things, common words and so forth out of a dictionary. There is one set up by default but it’s not enabled and you could enable that if you wanted to. Okay, let’s go ahead and drop to a command shell. I want to show you a few other things I want to change to root first because we need to be root to look at the shadow file. So let’s put in root’s password and the first thing I want to look at is the Etsy password file itself. And we’ve seen this before in an earlier session, but I want to just refresh you on it. You’ve got the username and you’ve got the X.

And the X is typically where the password used to go in older Unix implementations. Now that it’s encrypted, you just see the x there and the encrypted password is actually stored in the Etsy shadow file. We do this for security. Everyone can read the Etsy password file and the root has control over it. Now only root can typically make changes to the Etsy shadow file unless you change your own password. You can change your own password if you’re given permissions and that is the default. So you see the user accounts, you see their groups, their descriptions and so forth and their default shells. So that’s where a lot of the user account set up comes from. Let’s go ahead and look at the Etsy shadow file and we see again user accounts but this time we see the passwords. Look at the Bobby account here. This is the actual encrypted password that I use.

Now Unix salts passwords and now under Solaris eleven it uses Sha 256 versus older encryption mechanisms, older hashing mechanisms. So these are much more secure. So that’s what’s in your Etsy shadow and that’s where that’s controlled. Typically only root has access to that unless you change your own password. Now let’s look at a couple of other things. Let’s look at LDAP for a second. If we just do an LDAP client help, these are the different options we can use to set up an LDAP client if we have an LDAP server on board already and we would need that to set this up. We’re not going to set one up today because we don’t have an LDAP server running somewhere. Now you can also look at the different packages that are set up on the box already for LDAP. They’re installed, but they’re not enabled, the services aren’t enabled and we’ll see that in a moment. Let’s look at LDAP and that’s the actual LDAP package. And then if we look at OpenLDAP, that’s the LDAP server. The LDAP package are just the utilities.

The LDAP server, the open LDAP is the actual server itself. So you see that they’re installed and you can actually use them. So you don’t really have to do too much to set up LDAP as a server and service on your machine. But if you want, go ahead and look at services A and pipe that into grip and you’ll see that the services are actually on the box installed, but they are currently disabled. So you would have to enable them and configure LDAP on the box. And there are some LDAP commands that you can use to do that. So now we’ve looked at the local files and we’ve looked at LDAP files on the box. We’ve seen how Etsy shadow and Etsy password, etsy default password work and we’ve seen the different LDAP packages that are installed. And look at the LDAP services.

9. Access and Authentication Issues

Now let’s look at troubleshooting access and authentication issues. Now, access issues usually come from different permissions rights or privileges or authorizations not configured correctly. And that could be either on the resource itself, such as a file or a configuration setting in the system, or even a service. Could be a role or a group that’s not configured properly. And it also could be too much or not enough privileges or rights granted to a user or to a role or group even. We also know that some of these issues could happen when you grant these permissions, rights and privileges to individuals versus groups or roles. What may happen sometimes is an individual gets certain rights and privileges over time that they may not need. This is called privileged creep and sometimes they’re put into groups later, or roles are assigned to them. And because they have conflicting permissions between themselves and the role that’s assigned to them, there could be permissions and rights and privileges issues. So you may see those manifested by them not being able to do what you think they should be able to do, or them being able to perform actions or access resources they should not be able to. So sometimes you have to troubleshoot that down and figure out where the disconnect is. Sometimes you can assign the wrong role to an individual or put them in the wrong group, and that happens sometimes. So it’s a good idea to periodically review those groups and those roles.

Now, some troubleshooting steps and tools that you can use to check access and authentication issues. First of all, check the UID of the user. Sometimes you can be logged in as a user and think you’re logged in as a role. And you might want to do a who am I? Or the short form who am I? And see exactly which UID or user you currently are. It’s easy to try to be doing something and think you’re in the root role or using the root role or su to root and not be that. And so you get these different weird errors. You won’t always get access denied errors. You may get certain errors, like, for example, trying to cat the Etsy shadow file if you’re not logged in as the root role will get you a weird error. So you may not be able to do those things. Also, look at the Roles command, dual roles and User to see what roles they actually have assigned to them. You may think that they have a certain role that they don’t. You can also use the Auth command to check the authorizations for different users. You can use this to figure out exactly what authorizations they have both assigned to them as individuals and assigned to them through roles. You also may want to look at the role itself and see what authorizations it has assigned to them. Maybe the user has the correct role assigned, but the role itself does not have the correct authorizations, so check that as well. You also want to check permissions on files periodically. You want to check your system you mask and make sure that it’s set the way you want. Remember that the default is 0022 and that gives you a default permission set and that’s what new files will have when they’re created. Now, if you change the Umask and files don’t have that same default permission set, they may have been created before the Umask was changed. You may have to go back and do a Chamod on the individual files that you’re looking at. And it’s generally not a good idea to randomly and massively change permissions on files because you probably want certain files to remain at their system defaults. If you start changing file permissions willy silly, you may prevent someone from accessing a file or a whole group of people from accessing a file. And it may be a system file required for, let’s say, read access that everyone needs to log in with. So be careful with that. Some of the things you should avoid doing is you should avoid fixing any authentication or access issues by over granting privileges. Don’t, in the spur of the moment think, well, they need this access, so I’m just going to go ahead and grant them everything for now and I’ll fix it later.

Fixing it later typically does not happen and you’ve violated the principle of least privilege by giving them too much and then they may be able to do things you don’t want them to do. Also avoid granting these rights and privileges to individuals. Use roles instead, that’s what they’re there for. It’s a much better way to manage your rights and authorizations and privileges. Also use groups for permissions. Some people may try to delete and recreate account if they can’t fix the issue with user access. This typically won’t fix anything because typically the role may be the issue or the rights and privileges assigned to them may be the issue. It’s also a very good idea over time to record and document who has what privileges. And this especially applies to higher level or elevated privileges, things that may require the root role, for example, or the authorizations to modify or manage a service.

You typically won’t record these elevated privileges down somewhere in a database, possibly in a spreadsheet, whatever. So you can check that periodically and make sure that people have what you think they have. This can avoid something called privilege creep, where they get more privileges over time by changing groups or roles than they need. It’s a good idea to look at these elevated privileges and permissions and review them periodically just to make sure that everybody has what they’re supposed to have so that, you know, so when it comes to troubleshoot, you can actually troubleshoot the issues because you already know who’s supposed to have what. So it’s a very good idea to do that so that’s just some basic troubleshooting suggestions that I have for you and some basic tools that you can use to troubleshoot access and authentication issues.

10. For the Exam

Now that we’ve talked about controlling access to the system and to files and also authorization and so forth. We’ve talked about some really good security topics here. Now, this was just a surface treatment. There’s so much more we can learn about security than we’ve covered in just this basic course. But again, we’ve covered what’s necessary for the OCA exam and we’ve given you a few little extra things here and there to think about as well. First of all, we looked at access control basics, and you need to know these for the exam. You need to know how user IDs, usernames and passwords work. You need to know how you can put people into groups and assign them roles. And you need to know how to manage these roles using the Role Ad Command. And you need to also understand why you would put them in certain roles and how you would set up authorizations for those roles. We also talked about rights, privileges and permissions, and we covered the very basics of them.

We talked about what you would use rights and privileges for in terms of taking actions on the system and permissions that are assigned to resources. We also looked at access to systems. We looked at the different things you can do to control access, things like managing your user accounts, obviously properly, and your roles. But we also looked at service control, deleting the services or disabling the services rather that you don’t need. And this can be a hairy task. You have to really know the system and what services you need in order to do this.

We also looked at things you can do like patching and verifying packages, because patching is very necessary to prevent new vulnerabilities from affecting your system. And verifying packages will help you to make sure that they come from a trusted source. And while auditing really isn’t one of the exam objectives, we talked about a little bit in terms of that you should audit what users do and know what they are doing on your system. We also looked at controlling access to files. We talked about file permissions read, write, execute and their octal values and how they’re displayed, for example, in a directory listing and what they mean. We talked about the default Umask and how you could change it and why you have the Umask, basically for determining what the default file permissions are when a file is created. We also talked about owners groups and others, and those are the folks who get permissions to files and resources. We looked at authentication and we talked about local authentication, in other words, files based authentication, things like the Etsy password and Etsy shadow files. We looked at what those were and what they mean.

We also talked about network based authentication schemes such as LDAP, the Lightweight Directory Access Protocol, and Nissan Network Information Service. We talked about how LDAP is pretty much the newer thing and it’s pretty much what most people are using in their authentication schemes are network based, and this is a little bit older. And unlike LDAP, it’s a flat file and it has no security. Not many people use NIST anymore, and you might use it in a low sensitivity environment. We also discuss troubleshooting access and authentication issues, and pretty much most of the things you can nail down are too many or too little permissions, rights and privileges. And this could come from a wide variety of reasons. Maybe users don’t have the right roles assigned, or the right roles don’t have the right authorizations assigned to them.

Maybe the permissions aren’t set correctly on a resource, or maybe they’re not assigned to the right group. In any case, mostly with troubleshooting access and authentication issues, that’s typically the problem. It’s incorrect assignment of roles in groups, wrong permissions, and so forth. So you’ll have to actually kind of nail down where the problem is. It may take a little bit of troubleshooting, but we’ve given you some tools and suggestions on how to do that. So that’s what you’ll need to know. For the exam, please take the time to sit down at the solaris box you’ve installed. Practice these issues, create files, assign permissions to them, create users, add them to roles, create roles and assign authorizations to them. That’s about the only way you’re really going to learn this stuff really well for real life, which is the most important thing, and for the exam, which is also important. So practice makes perfect, or at least will help you pass the exam. And obviously review this VTC course, these particular sessions on access control, and that will help you out as well.

• Category: Uncategorized