Sarbanes-Oxley legislation (passed by our US Congress) is requiring our auditors to force “segregation of duties” among the IS and Functional staff.

I am the only one that supports Baan at our facility. Since I am the “SuperUser” AND I do development, the auditors are concerned that I could create malicious code and migrate the software components to production.

To get around this issue, management has decided that I can still do development on our TEST server and I still need to be able to perform my System Admin functions (as a SuperUser) in Production, but I can not do development in Production. (Which I can limit by removing my developer authorizations in Production.) By creating procedures that documents all my development, end-user testing & sign-offs and then handing that “work package” to my Network Admin (who has been trained to check various things and then perform the specific task of "importing data dictionary" in Baan) to move the components to Production. This process would seem to satisfy the auditors.

HOWEVER, the “Import Data Dictionary” session requires my Network Admin to be a Superuser AND have development capabilities, that –in effect- just created the scenario that the auditors are trying to prevent!!!

The reason I am trying to do this is that I need the capability to give my Network Admin ONLY the authorizations he needs to perform this task – and, by nature, that would be a “Normal user” given very specific session authorizations.

Any thoughts or insight on how to handle this situation would be greatly appreciated!!!

-Marine

Hmm.. can't you just give the normal user permissions to the Import / Export session? I would not think that you need to make them a superuser. I have not tried just that session in particular, but I have worked as a developer where they set me up as a normal user and gave me access to only those tools sessions they wanted me to have....

What error does it give you trying to access that if you are a normal user with permissions for that session?

For example: "Export Data Dictionary" - I get the Fatal Error: can not start session.

I gave inclusive permission to "Import Data Dictionary" and it seems to start the session, (I do not get a fatal error) but a message box comes up and states: "You are no superuser. You have no authorization" and prevents me from continuing. Baan support states that it is hardcoded to check if you are a superuser.

Ouch. ok, special code there then.

One thought is to automate the procedure with a super user login through OLE or some VB process, then put your own password on that. They would only be able to run your program, and that process would log into Baan as a superuser and run the Import or Export.

You can check the boards for how to write a VB program to call a Baan session, or through OLE. A few ways to do it...

To meet SOX requirements of separation of duties you have a few ways to go about it.
We have limited access to the sessions by the menu structure. You must also take away shell access so they can not launch the session from outside the application. Make them a "captive" user.
This restricts their access to only what is on the menu. As long as you can prove they can't get outside of this, it doesn't really matter what the authorizations say.
One further - this is being monitored - at the unix level and in the application. We create weekly reports of super user activity that are reviewed by management to make sure no one is doing anything they aren't authorized to do.
This meets SOX requirements.

Well, in Baan IV at least, you can run Baan from the command line, and put in a session, or menu for that matter, to start up in. As a superuser, it would run.

Reports and such may be sufficient to check for people doing that.

"captive user" means they can not get to the command line. when they log onto the server, they go directly into the application. All our users are captive. And unix level accounting will catch if someone does that and well as session history.

Marine, here are few thoughts on the issue -
I am the only one that supports Baan at our facility. Since I am the “SuperUser” AND I do development, the auditors are concerned that I could create malicious code and migrate the software components to production.
HOWEVER, the “Import Data Dictionary” session requires my Network Admin to be a Superuser AND have development capabilities, that –in effect- just created the scenario that the auditors are trying to prevent!!!
The reason I am trying to do this is that I need the capability to give my Network Admin ONLY the authorizations he needs to perform this task – and, by nature, that would be a “Normal user” given very specific session authorizations.
I am in the similar role and classified as Software/Systems engineer so that I can do both. I am a superuser, I have all package VRC authorizations, my login as well as bsp.
The way to get around is that all the main directories are locked down on unix for all users (including bsp) and the developers can only put components in emergency VRC after manager's approval. Only bsp can write to the baseline packae combination/VRC.
To meet SOX requirements of separation of duties you have a few ways to go about it.
One thought is to automate the procedure with a super user login through OLE or some VB process, then put your own password on that. They would only be able to run your program, and that process would log into Baan as a superuser and run the Import or Export.
To make our process accepted, a production-control/code-deployment team was formed and they execute the code migrations as we documented/designed with our own custom tools, PMC etc.
One further - this is being monitored - at the unix level and in the application.
We have automated scripts which are executed by job scheduler to automatically fix permissions at Unix level.

We have limited access to the sessions by the menu structure. You must also take away shell access so they can not launch the session from outside the application. Make them a "captive" user.
This restricts their access to only what is on the menu. As long as you can prove they can't get outside of this, it doesn't really matter what the authorizations say.
Well, in Baan IV at least, you can run Baan from the command line, and put in a session, or menu for that matter, to start up in. As a superuser, it would run.
Lisa is correct, the startup sessions work for almost all BaaN versions. All the role authorization templates should be foolproof to prevent unauthorized access to any session. Furthermore, you also have to look into the company/logistics or financial data access.
"captive user" means they can not get to the command line. when they log onto the server, they go directly into the application. All our users are captive. And unix level accounting will catch if someone does that and well as session history.
This should also include transaction audits.

All the above issues are only for BAAN end. There would be more to handle with root access from Unix Admins (you need that for porting set installations), DBA access (you need that for new database setups, killing hanging/blocking locks/sessions, create/delete users etc), password aging, password changing policies etc etc.

I will take a break and stop here :p

Good Luck :) with SOX implementation.

For outside of Baan we use sudo. This works two fold inside of baan if you are using an ascii interface.
We track the dba and root logins and all unix commands using unix accounting. (yes, the files are huge) CA has a neat tool we were testing (not sure where that ever went ) that audits the access and what is done on a unix server.

Our root and DBA ids are only accessed through sudo unless you have an exception from your mother, great grandmother and queen of england to have access to the password.

I think we've covered just about everything.

I'm sure you've smoothed it out for your processes. Just want to clarify, by Command Line I guess I mean not just ASCII. When you run the BW for Baan GUI, in the 'Command' option and put in a startup session or menu, among other things. They should not have access to the 'Config' option of the BW. You can, of course, lock that down too, or auto start and not give them access at all as you have done. Just want to mention it as something that needs to be looked at.