Security is one of your most important tasks as a network administrator. You need to make sure that users are who they say they are and that they have proper access to the network. However, try as you might to set up security policies on your network, users may attempt to find ways around them. In this Daily Drill Down, I’ll show you how you can use NDS to enforce the restrictions and policies you have on your network.
Striking the proper balance
Even though network security is important, you should keep a little perspective. Don’t forget that, as important as security is, you’re still providing a service to your end users. Some network administrators have a tendency to go on a power trip as soon as they’re given the Admin password. They lock down everything in sight and become very antagonistic towards their end users.
You should work with your end users, their managers, and your manager (if you have one) to establish the proper level of security for your network. Take time to explain to your users why security is the way it is. They may not like the idea of having unique user IDs or changing passwords every so often, but they’re less likely to complain if they understand why these policies are in effect.
That said, there’s little reason for having security policies if your users fight against them at every turn. You may create user IDs on your network for certain purposes, only to discover that everyone is sharing the same username and password. You may even discover users logging into machines that they shouldn’t be.
Fortunately, NDS and NetWare give you the ability to enforce certain restrictions on your network. You can enforce passwords, login times, the number of simultaneous logins, and many other options. As with most things in NDS, you can perform all of these tasks from your administrative workstation using the NetWare Administrator utility.
Unfortunately, you can only make the changes I’ll discuss on one user object at a time. You can’t globally change all of the properties. However, you can create a user template that contains the restrictions and other properties you want to apply to future users. You can then create users with those settings using the template. I’ll show you how to create and use user templates in another Daily Drill Down.
Enforcing concurrent logins
Sharing user IDs and passwords can be a big problem. Rather than taking the time to remember their own user ID and password, users just may share one ID that has the access they think they need. While that may make things easier for them, it makes it next to impossible for you to track what’s going on. It also defeats the purpose of having user IDs to begin with. If everyone logs in using one ID, then why have logins in the first place?
You can fix that problem in NetWare Administrator. After you launch NetWare Administrator, double-click the user ID you want to change, and you’ll see the Properties notebook for the user object. If you click the Login Restrictions tab, you’ll see the screen shown in Figure A.
|The Login Restrictions screen enables you to restrict simultaneous logins.|
Select the Account Disabled check box to prevent a user ID from working, without deleting it. You can also cause a user ID to expire at a certain time in the future by selecting the Account Has Expiration Date check box and setting the appropriate date and time.
By selecting the Limit Concurrent Logins check box, you can place restrictions on the number of simultaneous logins a particular user ID can have. The default setting is 1. You can change the default by entering a new value in the Maximum Connections field.
Although limiting concurrent logins can solve the problem of users sharing IDs and passwords, it can be a cause of annoyance to your users as well. If a user forgets to log off of one machine, walks across the room (or worse, across the building or campus), and tries to log in, naturally they’ll be blocked. Likewise, concurrent login limitations can be annoying when a user’s machine crashes. When their machine boots back up, NDS may still be holding their old connection open. The user won’t be able to log in until NDS times out and clears the old connection.
Enforcing password restrictions
You can also place restrictions on the types of passwords your users use and how often they must change them. To do so, click the Password Restrictions tab. When you do, you’ll see the screen shown in Figure B.
|You can place restrictions on the way your users utilize passwords.|
As you can probably guess, selecting the Allow User To Change Password check box enables users to change their own passwords. This keeps you from having to do it for them.
You should select the Require A Password check box as a matter of course. This requires the account to have a password. When you select Require A Password, the Minimum Password Length field and the Force Periodic Password Changes check box become available.
Naturally, the Minimum Password Length field controls how short a password can be. The default length is five characters. You can make it shorter if you want to, but it’s not a good idea. If anything, you should make it longer than the default. Short passwords are easy to crack if someone plays Guess-the-Password.
Selecting the Force Periodic Password Changes check box allows you to force users to change their password on a regular basis. This prevents users from using a password that a coworker could find out about and use. When you select this check box, the Days Between Forced Changes field becomes available. The default value for this field is 40 days.
You can change this field to any number of days from one to 365. However, you should be careful when choosing the proper number for password changes. If you set the value too high, the passwords will never change, and you will have set this setting in vain. Setting the value too low will cause your users to start writing their passwords on Post-It notes attached to their monitors, thereby creating a huge security hole. My personal preference is to set this value for 60 or 90 days.
You can prevent users from constantly reusing the same passwords by selecting the Require Unique Passwords check box. When you select this check box, NDS remembers the last eight passwords a user has entered. When the user changes their password, they’ll have to come up with a new one. After they’ve selected the ninth password, their first one can be used again. Users normally dislike it when you use this setting because they have their favorite passwords. Encourage them to be unique when choosing new passwords. Sometimes they sequentially add a number to their favorite password—acme, acme1, acme2, and so forth. As you can imagine, that makes Guess-the-Password much easier.
The Limit Grace Login check box allows you to limit the number of times a user can log in after their password has expired. NetWare is somewhat forgiving in that it allows you to let users log in after they should have changed their password. They’ll get a nasty warning to reset their passwords, but that’s it. By selecting the Limit Grace Logins check box, you can stop that. After the number of grace logins that you specify is used, the user can no longer log in.
The last option on the Password Restrictions screen is the Change Password button. You’ll have to use this when you want to reset users’ passwords. You can never see a user’s password, but you can change it whenever you want. You’ll use this option frequently when users call and tell you they’ve forgotten their passwords.
Setting login time restrictions
NDS also allows you to control when your users are allowed to use the network. If you click the Login Time Restrictions tab, you’ll see the screen shown in Figure C. This tab enables you to lock users out.
|You can restrict the time when users can access the network.|
When you click a square in the grid on the Login Time Restrictions screen, the square turns gray. The user can no longer log in at this time. Each grid represents one half-hour.
If a user is already logged in, the server will warn them five minutes before the time restriction takes effect. If they don’t save their data within that amount of time, the server will disconnect them. Their workstation will continue to run and save locally, but they won’t be able to use any network resources.
Keep in mind that the times specified in the grid are based on the time zone in which the server resides. If your server is in the Eastern Time Zone, and you have users logging in from the Central Time Zone, you’ll have to mentally make the adjustment and change the restrictions in NDS accordingly.
Restricting login locations
Click the Network Address Restriction tab to see the screen shown in Figure D. From this page, you can link the user object to a particular network address. You can choose to restrict the user’s login by the following protocols:
- Ethernet/Token Ring
|You can restrict a user ID to a particular network address.|
The most useful of the choices under Network Protocol is Ethernet/Token Ring. With this choice, you can tie a user ID to a specific network card, which will also tie the user ID to a specific computer.
While the other protocols will also theoretically allow you to tie the user ID to a specific computer, you may run into problems. For example, if you try to restrict by TCP/IP address and have a DHCP server on your network, the computer may be given a TCP/IP number that the user can’t use.
However, if you restrict by Ethernet/Token Ring address, the user ID is tied directly to the network card inside the computer. This number is contained in the network card’s hardware and doesn’t change. The only way the user would be able to use a different computer would be to physically remove the network card.
As you can probably guess, restricting network addresses can create administrative headaches. If you restrict by Ethernet/Token Ring address and the card fails, you’ll have to remember to enter the address of the new NIC when you replace the one that failed. You’ll also have to know the NIC address if the user gets a new computer or transfers to a different department.
The Network Address Restrictions field is multiple value, which means that you can restrict the user object to multiple locations. If the Network Address Restrictions field is empty, the user can log in anywhere. If you add a value to the field, then from that time on, the user can only log in from the addresses listed in the field.
Security is one of your most important jobs. NDS and NetWare give you many different properties you can control in a user object that allow you to enforce your network’s security policies. In this Daily Drill Down, I’ve shown you several restrictions you can place on user logins using NetWare Administrator.
John Sheesley has been supporting networks since 1986, when he got his hands on NetWare 2.2. Since then, he’s worked with the Jefferson County Police Department in Louisville, KY and the Genlyte-Thomas Group. John’s been a technical writer for several leading publishers, including TechRepublic, The Cobb Group, and ZDJournals. If you’d like to contact John, send him an e-mail .
The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.