I think you need to sit with your security people and lay out all of these concerns to see what you can come up with. A lot of what you are saying looks like its a process issue. For the example you just gave, you should either be disabling the generic admin Accts like Demo or change your process so that if a person with Admin access gets canned or leaves the organization, you need to change those passwords immediately as he/she is being walked out of the door or in their exit interview with HR. I know this scenario from working with a lot of short term consultants and it's handled by: 1: Not giving them all the keys to the castle if they don't need it (Demo pw etc...) 2: Disabling their access when they are done "touching" the system. 3: Implement a layer of security on top of your public domain address like a token authentication or passphrase.
Sent from my iPhone On Sep 6, 2013, at 4:57 PM, SUBSCRIBE arslist Aditya Sharma <[email protected]> wrote: > That is just an example.. Yes everything is password protected always. > > If I had an admin guy who knows one of the generic admin account present on > the system and guy is now not part of organization, but he still can access > the company URL through internet.. as the generic account may be used by > several people at a time and those passwords may not be changed so > frequently. May be too complex or have limitations for non-workflow > implementation but this is a very genuine use case. > > > Sent from my BlackBerry® smartphone from !DEA > > -----Original Message----- > From: Joe D'Souza <[email protected]> > Sender: "Action Request System discussion list(ARSList)" > <[email protected]> > Date: Fri, 6 Sep 2013 16:46:08 > To: <[email protected]> > Reply-To: [email protected] > Subject: Re: Prevent MT Login > > First of all why is your Demo user not password protected? That's a bad bad > thing.. > > No other user on your system except your admins should have admin access > rights. > > Configure your system that no guest users are allowed to login - simple > check box on the server information page.. > > Plus you can use any combination you are comfortable with on suggestions > given on this thread.. > > Joe > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of SUBSCRIBE arslist Aditya Sharma > Sent: Friday, September 06, 2013 4:40 PM > To: [email protected] > Subject: Re: Prevent MT Login > > For ex. > > User- Demo > Is default admin account, not all thousands of user has access to dev studio > or client tool in cloud world, but if somehow that account is left as it is > and randomly some guy try to login to the URL with this and able to get in, > no wonder there is an easy chance he can blow up configs and inturn the > system if he want's ;) > > So just looking for all possible ways to prevent such situations. > > We do have workflow mechanism implemented, but non-workflow can make it more > portable to add or remove such restrictions for multiple users easily. > > Thanks for all suggestions. > > > Sent from my BlackBerryR smartphone from !DEA > > -----Original Message----- > From: Joe D'Souza <[email protected]> > Sender: "Action Request System discussion list(ARSList)" > <[email protected]> > Date: Fri, 6 Sep 2013 16:32:05 > To: <[email protected]> > Reply-To: [email protected] > Subject: Re: Prevent MT Login > > Prevent guest logins.. > > Joe > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of SUBSCRIBE arslist Aditya Sharma > Sent: Friday, September 06, 2013 4:30 PM > To: [email protected] > Subject: Re: Prevent MT Login > > Client tool I do not only refer to User Tool.. It can be dev studio, spoon > client, import tool etc.. this solution if possible through a non-workflow > mechanism can help in preventing unnecessary login through generic accounts > over web URL which is available over internet.. Client tools access we can > restrict through VPN or other ways. If there can be a mechanism to blacklist > some accounts to login through web; This can be one of the major security > requirements to make sure Admin accounts are not misused. > > Sent from my BlackBerryR smartphone from !DEA > > -----Original Message----- > From: Joe D'Souza <[email protected]> > Sender: "Action Request System discussion list(ARSList)" > <[email protected]> > Date: Fri, 6 Sep 2013 16:02:47 > To: <[email protected]> > Reply-To: [email protected] > Subject: Re: Prevent MT Login > > PERFORM-APPLICATION-LOGOUT from the home page or any other page that the > user might have access too if the $CLIEMT-TYPE$ = 9.. > > Why would you have such a requirement though when the future versions does > not support access through the native User client? > > This is a workflow mechanism - it will be impossible to do it with a non > workflow mechanism. Unless you are free to employ a security guard to stand > besides that employee and beat the crap out of him if he tries to log in > through the mid tier.. That would be a non workflow mechanism :) - primitive > - but will work.. :) > > Joe > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of SUBSCRIBE arslist Aditya Sharma > Sent: Friday, September 06, 2013 3:59 PM > To: [email protected] > Subject: Prevent MT Login > > > Hi Listers, > > I have a requirement to prevent a particular user to be able login through > mid tier but same user should be able to login to client tools. Has anyone > implemented such requirement? What can be the best way to achieve this? > > Specifically looking for a non-workflow mechanism. > > Regards, > Aditya > Sent from my BlackBerryR smartphone from !DEA > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
