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