HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Root login
Operating System - HP-UX
1833779
Members
2060
Online
110063
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2001 06:28 AM
07-18-2001 06:28 AM
I had a funny thing happen this morning. We have a sudo script that we can run as administrators that allows us to reactivate the passwords if a user gets locked out. We have third party support that needs the root access and they locked root out this morning.
I went into SAM and modified the root password just before another administrator ran the reactivate sudo script. It locked everyone out of root. Then i went back into SAM and modified the the root password to its original password and logged out and it worked. The other administrators could not get into root.
Here is the script. Is there a gliche between the SAM modify password and the script we run?
#-- Set up globals
SCRIPT=`basename $0`
USAGE="usage: $SCRIPT [usercode]"
BOLD_ON=`tput smso`
BOLD_OFF=`tput rmso`
TCBDIR="/tcb/files/auth"
#-- Set up the FPATH environment for shell functions
export FPATH="/usr/local/functions:"
autoload FUNCTION_LIBRARY
#-----------------------------------------------------------------------#
# O U T E R B L O C K #
#-----------------------------------------------------------------------#
#-- Only the superuser may activate accounts
if [ `id -u` != 0 ]; then
print "Sorry. You must have superuser privileges to activate an account."
exit -1
fi
#-- Get usercode
USER=""
case "$#" in
0)
print "\nEnter a login name to be enabled or to exit: \c"
read USER
if [ "$USER" = "" ]; then
print "No user enabled."
exit 0
fi;;
1)
USER=$1;;
*)
print "$USAGE"
exit -1;;
esac
#-- Verify account
PWENTRY=""
PWENTRY=`grep "^$USER" /etc/passwd`
if [ -n "$PWENTRY" ]; then
FCHAR=`echo $USER | sed "s#\(^.\).*#\1#"`
if [ -r "$TCBDIR/$FCHAR/$USER" ] ; then
DONE=true
else
print "User ($USER) was not found in password database."
fi
else
print "User ($USER) was not found in the /etc/passwd file."
fi
#-- Allow operator a chance to bail out
print "\n\t$PWENTRY\n"
GET_YES_NO "Is this the entry you want to reactivate?"
if [ "$ANSWER" != Y ]; then
print "User ($USER) was not enabled."
exit 1
fi
#-- Enable the account just like SAM
/usr/lbin/modprpw -k "$USER" 1> /dev/null 2>&1
print "$BOLD_ON Account \"${USER}\" has been reactivated $BOLD_OFF"
exit 0
Can someone help me on this one? It looks as if this script doesnt work even if you go into SAM before you run this and modify the root password.
Chris
chrisam@rocketmail.com
I went into SAM and modified the root password just before another administrator ran the reactivate sudo script. It locked everyone out of root. Then i went back into SAM and modified the the root password to its original password and logged out and it worked. The other administrators could not get into root.
Here is the script. Is there a gliche between the SAM modify password and the script we run?
#-- Set up globals
SCRIPT=`basename $0`
USAGE="usage: $SCRIPT [usercode]"
BOLD_ON=`tput smso`
BOLD_OFF=`tput rmso`
TCBDIR="/tcb/files/auth"
#-- Set up the FPATH environment for shell functions
export FPATH="/usr/local/functions:"
autoload FUNCTION_LIBRARY
#-----------------------------------------------------------------------#
# O U T E R B L O C K #
#-----------------------------------------------------------------------#
#-- Only the superuser may activate accounts
if [ `id -u` != 0 ]; then
print "Sorry. You must have superuser privileges to activate an account."
exit -1
fi
#-- Get usercode
USER=""
case "$#" in
0)
print "\nEnter a login name to be enabled or
read USER
if [ "$USER" = "" ]; then
print "No user enabled."
exit 0
fi;;
1)
USER=$1;;
*)
print "$USAGE"
exit -1;;
esac
#-- Verify account
PWENTRY=""
PWENTRY=`grep "^$USER" /etc/passwd`
if [ -n "$PWENTRY" ]; then
FCHAR=`echo $USER | sed "s#\(^.\).*#\1#"`
if [ -r "$TCBDIR/$FCHAR/$USER" ] ; then
DONE=true
else
print "User ($USER) was not found in password database."
fi
else
print "User ($USER) was not found in the /etc/passwd file."
fi
#-- Allow operator a chance to bail out
print "\n\t$PWENTRY\n"
GET_YES_NO "Is this the entry you want to reactivate?"
if [ "$ANSWER" != Y ]; then
print "User ($USER) was not enabled."
exit 1
fi
#-- Enable the account just like SAM
/usr/lbin/modprpw -k "$USER" 1> /dev/null 2>&1
print "$BOLD_ON Account \"${USER}\" has been reactivated $BOLD_OFF"
exit 0
Can someone help me on this one? It looks as if this script doesnt work even if you go into SAM before you run this and modify the root password.
Chris
chrisam@rocketmail.com
Lifes too short to stress out, Enjoy every day you have on earth!
Solved! Go to Solution.
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2001 07:07 AM
07-18-2001 07:07 AM
Re: Root login
Just a couple of thoughts, probably red herrings:
your grep "^$USER" should end with a ":" to cater for usernames of roota, rootb, etc.
Also, it might be worth redirecting the output of the modprpw to something other than /dev/null, and check its exit status.
If the two operations were executed simultaneously, then some sort of lock contention may be the cause.
Robin
your grep "^$USER" should end with a ":" to cater for usernames of roota, rootb, etc.
Also, it might be worth redirecting the output of the modprpw to something other than /dev/null, and check its exit status.
If the two operations were executed simultaneously, then some sort of lock contention may be the cause.
Robin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-18-2001 10:27 AM
07-18-2001 10:27 AM
Solution
Hello Chris,
the "-k" option of "modprpw" can only activate users
other than "root" - there you have to use "-x" (or it
is the other way round - one is working for users, the
other for "root", at least).
And insert that ":" at the end of your pattern for that
"grep" command!
HTH,
Wodisch
the "-k" option of "modprpw" can only activate users
other than "root" - there you have to use "-x" (or it
is the other way round - one is working for users, the
other for "root", at least).
And insert that ":" at the end of your pattern for that
"grep" command!
HTH,
Wodisch
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP