AIX Down Under
You know when you go to the ATM or enter a PIN, you're told to cover up your hands so no one can look on. I wonder whether the same rule ought to apply for people on the bus who are on the phone. I've overheard passwords for what seem to be very important institutions, and I have enough non-AIX knowledge to know the root password (for Linux) or Administrator (Windows) is probably something precious.
For that matter, if IBM developerWorks - let's shorten it to ibmdw, had a root password that went something like 1bmdw123, I'd be a little worried. So why does ACME Corporation's support guy tell me - and everyone on the bus - that the root password is @cme123? Or if Fred Nurks' software runs NurksApp, would it be too much for all of their customers not to have a password such as nurk5@pp?
I have no idea if IBM developerWorks even has a root password, and I certainly hope there is no such software as NurksApp, or else my next post may be from a law court, but I think and hope that password policy has come along a little from the days when we can log in as root and have a pretty good wild guess at the password. Still, if I were a hacker, sitting and listening on the bus or train or metro is probably more helpful than doing a course on Cybercrime for Dummies.
I once heard of an Australian company with the password pajamas. (Incidentally, this was many years ago and many systems ago and so don't try to crack them). That was actually a pretty hard one to guess because in Australia, at least, we spell that word pyjamas (starting with py, not pa). The "Modern" US spelling comes from 1845:
1800, pai jamahs "loose trousers tied at the waist," worn by Muslims in India and adopted by Europeans there, especially for nightwear, from Hindi pajama, probably from Persian paejamah, literally "leg clothing," from pae "leg" (from PIE *ped- "foot," see foot (n.)) + jamah "clothing." Modern spelling (U.S.) is from 1845. British spelling tends toward pyjamas.
Yesterday you discovered that Australia's emergency number is 000, not 911.
See what you learn from following @1X D0wn Und3r?
Written by @nth0ny123
If you're unfortunate enough to lose the root password on an AIX host, there is a way of recovering it. You can also recover the padmin password in VIOS if you've lost it. Basically, it's a matter of booting from AIX or VIOS installation media and stepping through the System Maintenance menus. When you do that, the boot file systems come from the installation media, and then you import the rootvg volume group which is on the original disks (the one with the unknown password). At that point you can run the passwd command or edit /etc/passwd.
No luxury, no necessity
This procedure requires a reboot, and if you don't have that luxury, you may find you don't have the necessity of changing root's password. There are several back doors (or alternatives) which may allow you to have the equivalent of root access or set the root password anew. Here are some of them:
Booting from media
If you are left with booting from media, in this virtualised world, that's not as easy as the old days when you had a dedicated tape drive, CD-ROM or DVD-ROM for your AIX system. Today the slot containing such a device is most likely not allocated to the LPAR (now known as virtual server) which needs a root password recovery.
You could allocate the I/O slot to the LPAR, that is the I/O slot containing the adapter which connects the DVD-ROM. You could do this using Dynamic LPAR or by shutting down the LPAR, assiging the slot to its profile as Desired or Required and activating the LPAR.
Other boot options
Other ways of booting are using the Virtual Media Library, using NIM, or booting off a mksysb backup.
The Virtual Media Library would be my preferred option, since it's simple and quick to set up. I like to have my AIX "media" in ISO format permanently loaded in the Virtual Media Library on the VIO server. This works for lost root passwords on AIX LPARs. Unfortunately, this virtual media library option is not possible if it's the VIOS padmin password you've lost as the VIO server can't be a client of another VIO server.
NIM is also a popular option (both for AIX LPARs and VIOS), and it allows you to boot off an ethernet adapter (physical or virtual) which will see the boot device presented by NIM, if it's all set up correctly.
With both the Virtual Media Library and NIM you can use a mksysb backup or AIX installation "media" (although you're not using physical removable media such as a DVD).
I'm sure you could use virtual tape options or virtual CD-ROM without using the Virtual Media Library. You could do it this way if you had a bootable DVD (AIX installation media or a mksysb) allocated to a DVD-ROM which was owned by the VIO server. Then you could map that physical DVD to a VSCSI adapter on the VIO server and the client which had its password lost.
An unplanned outage is bad enough, but a planned one just because you had to recover a lost password can take some explaining. If you have a dual VIOS configuration and are confident that you can shut down / reboot one VIO server without too much fuss, you'll be glad about it. The AIX outage will depend on how critical the system is.
The root password recovery only really takes a couple of minutes (plus time to stop applications if you can, boot the LPAR and start apps again). Still, it's no fun having to arrange an outage at a busy time for a perfectly avoidable situation. It reminds me of G. K Chesterton's response when he was asked what book he would take if he were to be stranded on a desert island. I don't recall what the book was, but he prefaced his answer with the observation that he'd rather not make the trip in the first place.
Update: perhaps my memory is failing me. I looked it up and it turns out that Chesterton's choice of book on the stranded island was Thomas' Guide to Practical Shipbuilding.
AnthonyEnglish 270000RKFN Tags:  dos telnet aix_security_expert password denial_of_service aixpert tcptr login attack sox ftp ssh socks 11,892 Views
AIXpert and SOX (and sockets and Socks)
Over the weekend, a client implemented security hardening on their production LPARs. They used AIX 6.1 Security Expert. Apart from some users who had been locked out due to weak passwords, testing went well ... until about 9am Monday, when some users reported they couldn't log in.
Here were the symptoms:
only the sharpest mathematical minds would pick up:
A mathematical experiment
Gather together 11.8 friends - and yourself - and all take off gloves and shoes and socks to confirm the abovementioned amazing mathematical fact. You may need to find another 12.8 friends - if you have them - to do the comparison.
Well, one console session was accounted for, and the rest came down to a limit on the number of network connections allowed. Enter the protagonist of this drama, the AIX 6.1 tcptr command. That is the command which allows you to regulate the number of connections allowed for a range of ports.
The telnet port 23 and ssh port 22 were in the same range for tcptr. AND their limit was set to 256, as shown by the tcptr -show command. On top of that, ftp was permitted because it was on port 21 - a different range, with only one connection in use.
The tcptr command had been called by aixpert.
Fixing the problem was easy, once I understood the syntax of the tcptr command:
Once I increased the maximum connections for the port range StartPort=22 to EndPort=25, users were able to log in immediately. Which was just as well, because the Help Desk was then able to log new calls, including an environmental issue to do with a socks audit and bare feet in the office.
Once you've put your gloves on again, have a read of the man page for the tcptr command, and a developerWorks article on IBM AIX TCP Traffic Regulation.
Check the wiki on aixpert to find out more about SOX-COBIT compliance.
AnthonyEnglish 270000RKFN Tags:  unsuccessful_login locked_out smitty aix compassion forgot frown password lsuser account_locked chuser loginretries smit smile exercise muscle annoyance 18,782 Views
"Unlock my account please"
When users forget their Unix passwords you're likely to get the request to unlock their accounts. You might be surprised to see in SMIT that the account is not locked:
Lock / Unlock a User's Account
Is this user ACCOUNT LOCKED? false
Then you change the user's password and you have a happy user logging in again.
Three strikes and you're out
If the user couldn't log in, why did AIX report the account was not locked? The problem was that the user had exceeded his number of unsuccessful logins. Once again, in SMIT you can see when you add or Change a user:
Number of FAILED LOGINS before user account is locked In the example above, this is set to 3. This field is called loginretries on the lsuser command.
You can see how close the user is to the threshold via the lsuser command:
lsuser -a loginretries unsuccessful_login_count testuser
testuser loginretries=3 unsuccessful_login_count=2456
This guy needs to think of a different password next time.
Not locked out at all
This user hasn't been permanently locked out of the system any more than you've been permanently locked out of your own house. He's just lost his key.
The account_locked attribute is for users who are not supposed to login again. Ever. That's for people who have left the company, for example. The loginretries is different. It just sets a limit on how many times a user can forget a password before coming cap in hand to the friendly AIX sys admin for some help.
You can reset the user's failed login count in SMIT:
Reset User's Failed Login CountOr you could do it on the command line using chuser:
chuser unsuccessful_login_count=0 testuser
When you change a password for a user using the passwd command, that automatically resets the unsuccessful_login_count to zero. That's clever, isn't it?
Facial muscles advice for the AIX Sys Admin
By the way, when users are repeat offenders with forgetting their passwords, it's a real art to show compassion while maintaining just the right hint of ever-so-slight annoyance. Most people err on the side of the latter, which is probably OK. It's not easy combining a sincere smile and a frown all in the one expression, but think how many muscles get exercised when you try.