System Administation: Maximizing System Security, Part 1
Users don't like to change their passwords, and left to their own devices they will literally never do so. The shadow package includes an optional password aging facility which enables a system administrator to specify how often users must change their passwords. Whether using these features is necessary or not depends on the needs of your site.
Entries in /etc/shadow have the following format:
username:password:change_date:min_change:\ max_change:warn:inactive:expire:
where the first two fields are the username and encoded password for the account. The other fields relate to account expiration and password aging. [Note that in the shadow file, it cannot be continued across two lines, as we have done here to make it fit in the magazine—ED]
change_date encodes the date of the most recent password change. min_change and max_change indicate the minimum and maximum number of days between password changes, and warn indicates the number of days before a password expires that the user is warned of this fact. inactive specifies how many days after its password has expired that an account is automatically disabled, and expire encodes the date upon which the account itself will expire and be disabled.
Here is a sample entry from /etc/shadow:
chavez:XdleIqAert:9422:7:180:5:21::
User chavez can keep the same password for at most 180 days, and she will be warned 5 days before her password expires. When she does change her password, she must keep the new one for at least 7 days. If she doesn't use her account for 21 days, it will be automatically disabled. No expiration date is set for user chavez's account.
Once /etc/shadow is installed, it can be edited directly. However, the shadow package also provides tools for manipulating entries within it. Its version of the passwd command updates passwords within the shadow password file, and the command also has additional options for modifying the other password settings. For example, the following command changes the minimum password lifetime to 2 days, the maximum password lifetime to 1 year, the warning period to 3 days, and the inactive period to two months for user chavez:
# passwd -n 2 -x 365 -w 3 -i 60 chavez
If you wanted to remove all aging controls from an account, use this combination of options:
# passwd -n 0 -x 99999 -i -1 angela
These are the default values (along with a warning period of 14 days, which is irrelevant when passwords essentially never expire).
Account expiration dates are set with the usermod command. The following command sets the account expiration date to January 1, 1999 for user chavez:
# usermod -e 1/1/1999 chavez
Note that the useradd and usermod commands may also be used to create user accounts and specify or alter these and other account settings.
passwd's -l and -uoptions may be used to manually lock (i.e., prevent logins) and unlock an account respectively:
# passwd -l badboy
Finally, the chage -d command may be used to force a user to change his password at his next login; this option sets the date of the last password change field. It may be used to force a password change at a user's next login, provided that a maximum password lifetime is also set. Here is a simple script which accomplishes this:
#!/bin/csh
# force_change username -- run as root
chage -l $1 >& /dev/null
if ($status == 1) then
echo force_change: invalid user "\$1\"
exit 1
endif
set max=`grep ^$1\: /etc/shadow | \
awk -F: '{print $5}'`
chage -d `date +%D` $1
set today=`grep ^$1\: /etc/shadow | \
awk -F: '{print $3}'`
set yest=`expr $today - 1`
if ($max >= $yest) set max=`expr $yest - 1`
set date=`expr $yest - $max`
chage -M $max -I 2 -W 7 -d $date $1
The script extracts the current maximum password lifetime setting, sets the password change date to today, and then extracts the equivalent integer value (the number of days since 1/1/1970). It then sets the password change date to yesterday, reducing the maximum lifetime if necessary so that a password expiration is possible on that date. It also sets the inactivity period to 2 days and the warning period to 1 week.
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- RSS Feeds
- Introduction to MapReduce with Hadoop on Linux
- UX Designer




1 hour 18 min ago
2 hours 44 min ago
6 hours 54 min ago
7 hours 40 min ago
7 hours 50 min ago
7 hours 55 min ago
10 hours 5 min ago
10 hours 6 min ago
10 hours 51 min ago
11 hours 40 min ago