laura_albrecht_automic

Thoughts on Login Objects

Discussion created by laura_albrecht_automic on Aug 24, 2016
Latest reply on Sep 1, 2016 by brendan_sapience_automic
Hey there.  Just wondering what sort of philosophy people follow in regards to login objects.  At my old company we had one userid per login object.  Kept it very simple.  The userid inside the login object was also part of the object name.  

But I recently found out - or got the opportunity to use the feature where you can add your own login types (i.e. for internal apps) in UC_LOGIN_TYPES.

I also had a discussion with someone on why we have so many login objects - why not consolidate to a single login object?  I mean, I always knew you could do that, but just never really went that route.

In theory this sounds great.  I could put a Windows, UNIX, SQL, Service Manager userid / password in the same login object.  That'd be cool I guess - less objects.

But my problem comes with the fact that I have never tied a userid to a specific server / agent.  I always use the *.

So what do I do if I have 2 UNIX userids?  Now I can no longer have a single login object - I'd need two.  And if I have to do that, then the allure of having a single login object somewhat loses its appeal because now I'll have to know which userid is in which login object.

Just wondering what you all do out there.  Do you always tie a userid to a specific server?  Do you have multiple login objects?  Perhaps by application?  How do you handle this issue with multiple userids for the same platform type?

Just curious.  Still trying to avoid any major pitfalls before I get too far down the line.

Thanks.

Outcomes