Because of the Sarbanes Oxley act we have been reviewing what sessions our users get access to thru the DEMS. It appears that we get maintain sessions for some users that do not need them. We do not want to remove the "run" option from users, but they could(in theory) run these sessions. One example is it looks like everyone has maintain contracts. How do others handle this situation? We know we could delete the sessions authorizations or reset the times, but is there a better way or maybe another product that would help? Since we do not own source we can not even trace where some of the permissions comes from, but do know that it must be accessed from one of the standard Baan sessions. Any help would be appreciated?

Thanks

Mark

We do not want to remove the "run" option from users, but they could(in theory) run these sessions.
Mark,

If you are doing this for SOX, enabling the Run Option and letting the users wander in the Unix World is a security breach. Our end users do not have the run program/start-shell options.

I guess there should be options even in the BaaN-IV DEM to set session level authorizations.

In Baan IVc4 SP14 a new session "Maintain Session Authorizations by Session/User" (ttaad2132m000) has been introduced, see solution 135140. It's the inverse of the standard "Maintain Authorisation by User by Session" session.

You can then quickly set the access times for these sessions to 00:00 to 00:00 to prevent them being reset when regenerating DEM users.

Don't know if this will be helpful to you. Let us all know!!

Our users do not have start shell - at least most of them don't, a few special users do. The site I work at would probably want to through Baan out before giving up run program. Our experienced users do not like navigating the workflow diagrams. Also the UNIX level security should not allow them to do anything other than access to their home directories and a few other common directories that exist in production. You would not believe how many useless files(from excel downloads) end up in a home directory. The UNIX admins can not really write anything to clean these up because some of the Baan users have other apps that they use home directories for(pro/e, etc.).

As for ttaad2132m000 we do have that and yes we could do that, but we are talking about 300-400 users with multiple sessions(I do not have a count) that need to be set. I was thinking if I have to develop something I would use a function server to call this and set the times to 00:00 to 00:00 as was suggested. This is also what Baan support suggested. Just hoping something else exists.

Thanks

Mark

The site I work at would probably want to through Baan out before giving up run program.
Mark,

You can use Ravi's prototype code to simulate the Run Program option -

History of run programs (http://www.baanboard.com/baanboard/showthread.php?t=16513)

Thanks - I do not recall this post. I will give this as one of the options if they talk about removing run programs. At least then we can see who is doing what and log it.


Mark

Mark,

I thought I would share our experience with moving from DEMS. We are not as large a site as yours but we do have over 200 users (75 concurrent)

We moved away from DEMs for following reasons:

(1) Security Issues
Nearly impossible to tell who has what access since you have
both the DEM security and sessions secruity to deal with. There
isn't a good report that shows DEM security.
(2) Maintenance
Adding new custom sessions became a real nightmare.
Determining who had what flows and who needed them was very
timeconsuming. The original dems had been modified into
so many variations that it seemed every user had a custom flow.
(3) Support
Difficult to support users on different DEMS as sessions were often
named different
(4) Cost
We incurred cost savings by moving off DEMs

We did the following

(1) Created "Role Users" that have standard session security. Used/created some custom sessions allow for generation of user authorizations by role. Also allows the adding of a session to a role. I initial got this source from the old baanusers site and tweaked it. This is really key to quickly maintaining the security.

(2) Moved users to the main menu after creating their standard security role and provide navigation documentation/training to assist.

(3) For casual users (for us shop floor, invoice approval and sales people) we created a few custom menus with only those sessions needed by the casual users.

Note that overall this process took 2 years and required a of interaction with users. Many of the users complained heavily after being switched to the standard menu only to end up really liking them. This was by far the biggest obstacle (and also why it took so long). It was a very gradual process for us.

Summary of Benefits

(1) Maintainenance of users accounts takes about 85% less time
(2) Better Security
We had a ton of security holes using DEMS since we were controlling
the access via DEM and not via the standard security system.
It is very easy to control security now.
(3) Increased use of the system - users found other reports, functions
that they may not have had visibility
(4) Cross training of users - Users that move between job roles / functions
have easier time.. also we gained a lot of efficiencies due fact every
one sees the same thing. With DEM flows a lot of reports may have been
"hidden.

Thanks
Nathan

Nathan,

Another question for your "Role Users" how did you determine all of the sessions and sub-sessions needed to set them up? This probably one of the things that made it take two years.

Also - What about did you all do about process documentation? Currently our users point to the DEM - even though they really do not need them. It would probabl be better if our IT got out of the business of managing them and just provided a tool to the users.

Mark

We worked with different functional leaders on the sessions/subsessions. In some areas (like finance) this was easy. They provide us a list for each role. (I our controller a list of sessions in excel).

In other areas I took the flow sand determine which sessions were needed. We were very liberal in the "Display and Reports area" giving access to most reports/displays per role.

I also created some "session groups" which I used for building blocks to help build roles, i.e Basic user stuff, invoice approval, manufacturing reports etc.

The subsessions were still an issue. Basically we did it by trial and error. Move one user over and quickly add the subsessions as they needed them (and didn't have access).

Process definitions.
In some areas we left it up to a functional leader to define a quick navigation sheet. Again we found that a lot of places where flows were made the flow left out very useful reports.

Also, we now have modified certain "special" application menus to include all steps needed by user, especially pos, service orders, and sales orders. (BaaN has a lot of steps in some of these areas that are cumbersome for a sales/parts organization.) We also have been added some "supersessions" that use AFS to call sub session.

If you have any other questions or want a list of our roles/sessions let me know. I also have custom stuff for generating roles, adding sessions to roles etc.

Nathan

Thanks Nathan! I will keep this post in mind.

Mark