In a very security conscious environment the username of default admin account are usually changed and/or the account is disabled. In the Windows world I have heard of organizations renaming the 'Administrator' account so that is one less bit of info everybody knows about their environment. It might not be a bad idea to do the same thing with Demo. Now that installers use a special system account hopefully we will not have the dependency on Demo that we have had in the past.
Jason On Fri, Sep 6, 2013 at 2:10 PM, Tauf Chowdhury <taufc...@gmail.com> wrote: > 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 > <heloits...@gmail.com> 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 <jdso...@shyle.net> > > Sender: "Action Request System discussion list(ARSList)" < > arslist@ARSLIST.ORG> > > Date: Fri, 6 Sep 2013 16:46:08 > > To: <arslist@ARSLIST.ORG> > > Reply-To: arslist@ARSLIST.ORG > > 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:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Aditya > Sharma > > Sent: Friday, September 06, 2013 4:40 PM > > To: arslist@ARSLIST.ORG > > 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 <jdso...@shyle.net> > > Sender: "Action Request System discussion list(ARSList)" > > <arslist@ARSLIST.ORG> > > Date: Fri, 6 Sep 2013 16:32:05 > > To: <arslist@ARSLIST.ORG> > > Reply-To: arslist@ARSLIST.ORG > > Subject: Re: Prevent MT Login > > > > Prevent guest logins.. > > > > Joe > > > > > > -----Original Message----- > > From: Action Request System discussion list(ARSList) > > [mailto:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Aditya > Sharma > > Sent: Friday, September 06, 2013 4:30 PM > > To: arslist@ARSLIST.ORG > > 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 <jdso...@shyle.net> > > Sender: "Action Request System discussion list(ARSList)" > > <arslist@ARSLIST.ORG> > > Date: Fri, 6 Sep 2013 16:02:47 > > To: <arslist@ARSLIST.ORG> > > Reply-To: arslist@ARSLIST.ORG > > 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:arslist@ARSLIST.ORG] On Behalf Of SUBSCRIBE arslist Aditya > Sharma > > Sent: Friday, September 06, 2013 3:59 PM > > To: arslist@ARSLIST.ORG > > 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
