Hi Roger
in the an old redbook from adsm there was this information :
A) Authentication Concept TSM
(Source: Page 30 from the ITSO Redbock "ADSM Concepts" SG24-4877)
ADSM is a client/server application that operates over a network. In this
environment, someone can "masquerade" as either a client or a server. It is
important that the authentication be a two-way process where both client and
server verify that they are who they claim to be.
Mutually Suspicious
ADSM' s authentication is mutually suspicious. The client is suspicious of
the
server and the server is suspicious of the client until the authentication
process
is complete.
Password Not Sent across Network
During the authentication process, the password is not sent across the
network.
The authentication process is described as a "conversation."
1. The client begins the conversation by saying, "I am client X; if you have
the
same password that I have, you will understand this message." (The client
uses the password as an encryption key for the message.)
2. The server then receives t he message and responds, "I am server Y; if
you
have the same password that I have, you will understand this different
message." (The server uses the client's password as stored in the ADSM
database to decrypt the client' s message and to encrypt the server' s
message.)
3. Client X acknowledges that server Y is Ok.
4. Server Y acknowledges that client X is Ok.
This authentication scheme is Kerberos-like, where the trusted third party
is the
password.
Helge van de Kraan
Volkswagen
-----Ursprüngliche Nachricht-----
Von: Roger Deschner [mailto:rogerd AT UIC DOT EDU]
Gesendet: Donnerstag, 10. April 2003 01:31
An: ADSM-L AT VM.MARIST DOT EDU
Betreff: Better passwords in TSM
The state auditors are making us move to stronger passwords. We are
being required to implement the following in all systems, including TSM:
AUDITOR REQUIREMENTS:
1. Stronger passwords, required use of at least one lowercase letter,
uppercase letter, and digit. Minimum length 8 characters.
2. Password changes at least annually, IFF passwords are sent between a
client system and a server system in an encrypted form.
3. If sent in clear text, then password changes monthly with even more
stringent rules.
QUESTIONS:
A. Does the TSM client (all of them: GUI, web, and linemode
backup/archive, and Administrative) send the password to the TSM server
in an encrypted form, or in clear text?
B. Is there a way to enforce password strength rules? How can I tailor
those rules?
C. If not, is there a way to require all TSM clients to use Password
Generate? (The auditors seem to like what Password Generate does.)
D. If a client node has been using Password Generate, why does its
Password Change Date show up as a long time ago. Shouldn't it be the
date of last use, since Password Generate sets a new password with each
use?
E. Is there a way I can tell if a client uses Password Generate?
F. If a client node has been using Password Generate, and I change its
Password Expiration interval to something shorter than it was, which is
shorter than its Last Password Change date, what will happen? Hopefully
nothing at all - Password Generate will simply continue to operate.
G. How secure is Password Generate - really?
H. Is there any way to enforce the auditor's rules for Administrative
Clients?
I'm trying to avoid having all 1,000 clients call me on the telephone on
one day to complain that their passwords are no longer valid, while
still making the auditors happy.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
======= Warning: The Surgeon General has found that smoking may ========
======== cause some individuals to ignore the Surgeon General. =========
|
