account authentication with multiple passwords 1

[ggauthier]

(a) We've been asked to handle dual authentication for a single account; that is, one account has two passwords.

Preferred is option (b) that shell access is gained after two separate accounts and their respective passwords are successfully entered.

This is for a secured environment where multiple people need to be involved in order to access the system.

AIX has "auth2" as a user control, but auth2 "runs after the user has been authenticated by whatever was specified in auth1. It cannot block access to the system."

Well, if it does not block, then that's not what I am looking for.

Having someone access the system with "account a" and then su-ing to "account b" is not adequate. Access to the system itself needs two separate passwords.

Anyone have experience with either option (a) or (b)?

regards,
glenn

 

[khalidaaa]

Would that help in any way?

http://www.tek-tips.com/viewthread.cfm?qid=1363365&page=4

Regards,
Khalid

 

[ggauthier]

Hi Khalid,

Yes, that is what I am looking for -- but unfortunately, there are no posts confirming that it works.

Which manual were you referencing?

regards,
glenn

 

[RodKnowlton]

Having someone access the system with "account a" and then su-ing to "account b" is not adequate. Access to the system itself needs two separate passwords.

Then place the su-ing to "account b" in "account a"'s profile, followed by exit. Trapping for interrupts, of course.

Is the plan for any access to require two logins? Will it be one each from two different groups of people (ie management and staff), any two people from within a group, or two specific people?

The first gives a false sense of security (unless they're equally competent on the system and commands can only be executed after they each authenticate again, ad nauseum), the second is an implementation nightmare, and the last suffers from the "What if one gets hit by a bus?" problem.

Are you in a position to push back on this at all, or at least look to outside vendors with proven systems for this sort of thing (if they exist)?

- Rod


IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

A Simple Code for Posting on the Web

 

[ggauthier]

Rod,

There are no problem with buses

The system is in a locked cage with no fewer than 8 video cameras monitoring it. People who can unlock the cage do not have system access, and vice-versa. There are network ACLs maintained by people who do not have access to the cage or to the system. etc. etc.

I don't think pushing back is an option given the overall security measures.

The flexibility is whether the system mandates two separate accounts, or one account with two passwords.

I am reading up on Tivoli Access Manager to see what it offers.

thanks for suggestions,
glenn

 

[d3vzero]

Hi Glenn,

Have done this a few times, but it is complicated.

One of the problems with it is that the dual authentication cant work both ways, due to a infinite recursion trap.

This means that you can setup userA to login and work (after getting authorised by UserB), but you cant then setup UserB to require authentication via UserA.

If both users need to be able to work on the system, via authentication from each other, then each one will need two accounts for each user (one work account, and one Authentication account).
Messy I know. :-(

If you just have one user doing the work, but needing authorisation from another, then its alot easier.

First create a 2nd Authentication script called AUTHx2 in the /usr/local/sbin (or different) directory.

#!/usr/bin/ksh

/usr/bin/su - nobody -c "/usr/bin/su - $1 -c /usr/bin/id"
if [[ $? -eq 0 ]]
then    echo "Account Access Authenticated by $1."
        exit 0
else    echo "Account Access Failed to be Authenticated by $1."
        exit 1
fi

Then set its ownership and privs.

chown root.system /usr/local/sbin/AUTHx2
chmod 500 /usr/local/sbin/AUTHx2

Now edit the /usr/lib/security/methods.cfg file. and add the following lines.

AUTHx2:
        program = "/usr/local/sbin/AUTHx2"

Note that the above addition is for Aix 5.2 systems (not sure if 5.1 is included or not). If you are on 4.3.3 you will instead need the same mod but to the /etc/security/login.cfg file.

Now set the PRIMARY authentication method for UserA to also include the above script, with an argument specifying UserB to be used in authenticating access for UserA.

chuser auth1='SYSTEM,AUTHx2;UserB' UserA

If you need to change UserA's secondary authentication to a different user (eg UserC).

chuser auth1='SYSTEM,AUTHx2;UserC' UserA

Hopefully this will help you out.

Brgds, and Best of Luck.


____________________
Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debuging Mondays code.

 

[RodKnowlton]

Nice post d3vzero.

That gets a star and goes in my Google Notebook.

- Rod


IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+

A Simple Code for Posting on the Web

 

[ewhisper]

/usr/bin/su - nobody -c "/usr/bin/su - $1 -c /usr/bin/id"
why nobody?

the script doesn't work,look like this
$ su - testA
3004-501 Cannot su to "testA" : Authentication is denied.

 

[d3vzero]

Hi ewhisper,

The su - nobody actually forces the subsequent su to require a password.
Without it the subsequent su would always be successful, without any kind of authentication (due to it being executed as root).

Removing the su - nobody would null and void the entire purpose of the exercise, which was to force a secondary level of authentication (on signon) from a supervisor.

Dont try to use su. Instead use login to prove its functionality.
Logon as your testA user, and see if it works.

After you provide the password for the testA user, you should then be prompted for the password of your supervisor account (I assume its testB).

If you successfully provide both passwords, you should then gain access as the testA user.

If its still not functional, send the details of your configuration.
(Including Aix level).

Brgds.


____________________
Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debuging Mondays code.