RE: [U2] Uniobjects hack
Did you mean to say "carhacked"? Mind you, having a finger dangling from your key-ring instead of rabbits foot would sure be a "tip-off" at key-parties. S > What about the thieves who carjacked a Merc? Because it was > biometrically started, they chopped off the driver's finger so they > didn't need him to start the car. ** This email message and any files transmitted with it are confidential and intended solely for the use of addressed recipient(s). If you have received this email in error please notify the Spotless IS Support Centre (61 3 9269 7555) immediately who will advise further action. This footnote also confirms that this email message has been scanned for the presence of computer viruses. ** --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Uniobjects hack
Of course you could just stop anyone loading or using any development tools unless they are authorised to do so Making it a sackable offence usually works (I think that's a "pink sheet" for those on the western side of the Pond) Otherwise set the firewall to only accept connections on the UO port from designated IP addresses. Other techniques posted on the group will work as well - but to list a few: 1. firewall with nominated IP address interconnectivity ONLY 2. Restricted accounts with purged VOCs 3. O.S level permissions (or Tivoli Access Manager) 4. Triggers 5. Account level controls (remote verbs etc) 6. UO application-level authentication (suggest public key and one-time-pad for the serious - stops network sniffing) 7. Restrict access to Windows client PCs - stop anyone from doing anything untoward as they don't have permission to load or use that sort of software. 8. firewall 9. firewall I know I said firewall 3 times but I'll say it again *firewall* - there. Why? Because far too many people pay attention to firewalls - that's why I keep on saying use a firewall - yes really - firewalls are good ideas - yep so are DMZs with firewalls. See - I said firewalls again. BTW: Own up - who never changed their default RedBack administrator ID !!AND!! password. Own up folks - how many defaults are there still out there - we all know the default password I am sure? And yes - I have seen RBOScope access possible from the WWW with the default ID and password. Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] Re: Access to U2 Technical Notes
Ken/Dave, This is in fact a matter that I brought up at a recent IBM U2 Seminar in Melbourne, Australia, & which they agreed was an "issue", but gave no commitment to rectify. The way it works here is that IBM do not sell you a U2 licence - you have to buy it from a reseller (PRISM or MBS), consequently IBM tells you that "you are not "their" client'" so you do not have access to their secure technical notes. If you are an independant contractor, you also discover that none of the end-users are IBM clients are either, so you can't access the info via them. This is something that IBM really needs to address ASAP. MARY MULLANE > > I agree with you. I am a end-user and we do not have access to IBM'S > secure > technical notes. > > I understand that my company may be allowed to purchase software support > to > allow us to see these restricted documents. > > Ken Wallis <[EMAIL PROTECTED]> wrote: > And the good reason why IBM restricts access to this information so only > VARs and End-Users with direct support contracts can see it is? > > Why is this not in a publicly accessible piece of documentation? > > The number of times I have tried to register for an IBM techconnect ID > and > been refused because I'm a consultant not a VAR/End User is frustrating! > :-( > > Cheers, > > Ken --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Creating AIX Users for UniVerse
Also check out Sudo. sudo Sudo (superuser do) allows a system administrator to give certain users (or groups of users) the ability to run some (or all) commands as root while logging all commands and arguments. Sudo operates on a per-command basis, it is not a replacement for the shell. andy -Original Message- From: Rich Sias [mailto:[EMAIL PROTECTED] Sent: 28 May 2005 08:56 To: u2-users@listserver.u2ug.org; Dave Schexnayder Subject: Re: [U2] Creating AIX Users for UniVerse ** Reply to message from "Dave Schexnayder" <[EMAIL PROTECTED]> on Thu, 26 May 2005 10:32:01 -0500 > Hi Gals and Guys, > > We would like to release a administrative tool for our UniVerse/AIX (and > SCO) users which would allow them to create users on Unix and set their > passwords. > > Many of our users do not have IT staff and only do system management in Unix > when they have to. In reviewing the AIX documentation, I cannot find a way > around setting the password that is not interactive. > > In addition, the documentation states that other users can be promoted to > superuser. Has anyone done this for the purpose of creating users. Are > there any disadvantages to doing this? > > Ultimately, we would like an administrative user (other than root) to be > able to fill out a VB screen and upon acceptance, have it create a > functioning Unix user ready for login. > > Thanks, > > > Dave Schexnayder. :-) > Cheetah Advanced Technologies, Inc. On a system I worked with in 90's till 03, we had is as a two part process. One part was the app to interface with the "help desk person". It was a user interface querying for selected data items such as name, login id, creation, deletions, reset and other items we deemed neccessary. This apps only job is to collect the data and save it as a record. The other app is a phantom running as "superuser" in HPUX and when it noticed a record appeard, it would begin processing that record. It would revalidate the data fields again to be sure strings, numbers were what they were supposed to be and be limited to max character counts. Rejects were marked with errors and moved to logfile. Then it would process the data and using the superuser status execute login creation, update, delettion commands using the data provided. Either errors were attached or successful message attached and record moved to logfile. We recorded loginid for supervisor requesting, loginid of help desk person, time stamp at each interval of the process among other things. I later wrote a report for accounting dept that investigated an occasional activity or person looking for certain behaviour. Rich Sias - now looking for more dba work in Philly USA area. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
