On 07/11/2013 03:04 PM, Zoltan Forray wrote:
>
> What are your concerns?


It's forging a connection to our central enterprise authentication
source, with the explicit purpose of ignoring central enterprise
authentication.  I've still got a separate ID population, I'm just
storing them in the central bag of crap.   It's the Windows Registry
theory writ large.

I've got all the penalties of operational dependency on the central
directory server, and the recursive dependency problem in DR scenarios,
but I don't win the central ID vocabulary, and I can't set authority and
permission with the central group primitives.

If I could assign TSM administrator 'asr' to authenticate by using the
password associated with [domain]/asr, then that would be a huge win.
Password policy: *poof* dealt with.  Hell, ID revocation:  *poof*.
Suddenly it can be Not My Problem, do this with the central lifecycle
middleware.

Connecting the TSM infrastructure to AD, but _not_ letting my distal
admins authenticate to their AD credentials just looks dumb.   Actually,
it looks like politics.  If they let TSM use AD credentials, then Tivoli
directory server is damaged by that extent.

*shrug*

Anyway, I'm likely to use it:  to a man in the desert, brackish
swampwater will do.  But I can wish for some good old NYC tap, can't I?


- Allen S. Rout