I think he means the configuration manager in tsm itself, not the tme
onw (although called the same)

Can't you give them limited rights on the main server (only allow them
to change their own password, or is that not possible?

regards

Otto Schakenbos
System Administrator

TEL: +49-7151/502 8468
FAX: +49-7151/502 8489
MOBILE: +49-172/7102715
E-MAIL: oschakenbos AT teleflex DOT com

TFX IT-Service AG
Fronackerstrasse 33-35
71332 Waiblingen
GERMANY




Muhammad Sadat wrote:

Dear Steve,
I wonder if this question needed to be directed to TME10 mailing list.

Anyways,

If you have it all setup, that is, integration with Configuration manager,
then all you need to do is to give respective users the privilleges only to
manage TSM servers for these profiles.

On the other hand, changing password using Configuration Manager (to be
more precise Tivoli Management Framework) can be restricted if you set
appropriate user rights, but yes, there are more intricacies involved than
this.

Also if you are integrated with Active Directory, then you don't need to go
into the worries of changing passwords, because the users willl be
authenticated from AD server which will be contacted by TMF itself. Users
will change their password in AD and TMF needs not to worry about that.

Regards,
SaDaT





            Steve Harris
            <Steve_Harris@HEA
            LTH.QLD.GOV.AU>                                            To
            Sent by: "ADSM:
            Dist Stor                 ADSM-L AT VM.MARIST DOT EDU
            Manager"                                                   cc
            <[email protected]
            .EDU>


            08/30/2004 12:06
            PM                                                    Subject
                                      configuration management security
                                      question
            Please respond to
            "ADSM: Dist Stor
                Manager"
            <[email protected]
                  .EDU>






Hi all,

I'm designing a managed configuration of TSM servers.  Our management
structure here is a central TSM with level2/3 support functions, and some
district offices that will have their own TSM servers, plus some remote TSM
servers in their remote locations.

central ->[many districts]->[many satellites]

I'd like to manage as much of this centrally as possible.

Now I intend to set up adminstrator profiles on the configuration manager,
and all TSM Servers in a given district will subscribe to that district's
profile,
so any admin in a district will be able to administer any server in that
district, and only that district. This means that they have to log into the
config manager to update their passwords.

Now for operational reasons, theys guys will need unrestricted policy
privilege to do their work.  They won't be able to change any of the
policies that are subscribed from the config manager on their local TSM,
but what is to stop them from logging on to the config manager directly and
changing policies  there?

I could stop them from logging on to the config manager by locking the ids
there, since lock status is not distributed, but, then they can't log in to
change their passwords.


Have I missed something? How do others handle this.

Regards

Steve Harris
AIX and TSM Admin
Queensland Health,
Brisbane Australia








***********************************************************************************

This email, including any attachments sent with it, is confidential and for
the sole use of the intended recipient(s).  This confidentiality is not
waived or lost, if you receive it and you are not the intended
recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of
this email is prohibited.  It may be subject to a statutory duty of
confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this
email in error, you are asked to immediately notify the sender by telephone
or by return email.  You should also delete this email and destroy any hard
copies produced.
***********************************************************************************

otto.schakenbos.vcf
Description: Vcard