Why Role based Firefighter

Hello Folks,
What is the difference between Role based and Firefighter Id based Firefighting from an organization point of view.
The general practice is to go with Firefighter ID but I want to know a situation when Firefighter Role based strategy can be an advantage over the other.
In the user guide it is not mentioned when and why Role based Firefighter should be used.
Thanks in advance,
Amol Bharti

FF access via role assignments can be approved and provisioned in Access Enforcer (AE). Firefighter access can also be removed via Access Enforcer by submitting a request to remove the firefighter roles. FF access approvals are captured in the AE audit trail. The business reason for requesting/approving the access can also be captured in the comment section of AE.
FF access could be granted only after appropriate approvals EVERY time a user needs FF access. Each time a request for the FF role through AE (the request could go through a separate workflow path) and the request will be approved before being provisioned to the user. The approver can change the validity dates on the role assignment so that it can be provisioned for one day, for a week, a month, etc... An audit trail in AE will provide the approver information for historical purposes. This meets the policy of approvals every time FF access is provided instead of the 24/7 master data set-up in the original Firefighter process.
When running an SOD risk analysis on the user, the report will show the SODs the user has including their Firefighter access. (These SODs would then be mitigated per user even though they are a Firefighter.) There is a risk to the company when a firefighter can do one half of the risk on their own user ID and the second half of the risk on their Firefighter ID. Although this could still be caught, it would take some manual analysis. By using role-based Firefighter, all activities are performed and recorded under the user's normal user ID.
The Firefighter does not need to "check-out" a Firefighter ID the access is on their normal user ID.
The standard SAP audit trails have the user IDs instead of the firefighter IDs, so when researching the change, the firefighter logs don't need to be analyzed to see which user had used that Firefighter ID at that time.

Similar Messages

Role based Firefighter approach in AC 10

I am in the process of implementing "role based" FF (ID based approach not implemented as users are not comfortable to login to GRC system to execute the tcodes). I have a query about it.
If we maintain the role based FF logins, and we run risk report, still all the conflicts are found associated with that FF ids as they have the conflicting role assigned to them in SU01. So is it ok, to live with these conflict found related to FF ids. what will be the case during audit, will they accept these risks occuring for the FF can be ignored.

Hello,
I think the best approach is to mitigate the risk as Alexander describes here:
Why Role based Firefighter
Cheers,
Diego.

Role Based FireFighter with GRC 10.0 (CEA)

Does anyone know how the Role Based functionality of FireFighter exactly works besides putting the application type parameter to Role Based in SPRO?
The manuals explain that the FF users log in to the remote system with their own users, but how are the FF roles or roles that are enabled for Firefighting assigned to these users and how will the log file know which activity to record?

Good question, and the answer is not pretty.
In Role-Based Firefighter Application, the firefighter ID on the target system contains the user's regular access plus his/her firefighter access.
Reporting turns on when the user runs a transaction in the firefighter role.
If the transaction is in both the user's regular access and the firefighter role, reporting will turn on because the firefighter role access is in use.
The reports only track firefighter role usage. So if a user runs a firefighter transaction but also uses access defined in the user's regular access, the only thing recorded is the transaction.
If your company is not completely married to the idea of using Role-Based Firefighter Application, I suggest you consider the ID-Based Firefighter Application. In this, there are separate firefighter IDs on the target system and a firefighter gains access to them by going into GRC and completing a form showing how the firefighter ID will be used, and then the GRC system will let the firefighter into the target system using that firefighter ID.

Role Based FireFighter

Greetings All,
We are doing SAP GRC Access Control implementation in our company. We have Modulewise Master Roles working as firefighter Roles. In emergency we assign it to a user for 24 hours. Now when we are implementing FireFighter we want to keep existing Role Model but use the funcationality of FF. Have anyone gone through this scenario, do let me know the steps we need to configure the existing model with new FF Model and AE.
Thanks in advance,
Regards,
Sabita Das

Try Firefighter roles instead of Firefighter users.
FF access via role assignments can be approved and provisioned in Access Enforcer (AE). Firefighter access can also be removed via Access Enforcer by submitting a request to remove the firefighter roles. FF access approvals are captured in the AE audit trail. The business reason for requesting/approving the access can also be captured in the comment section of AE.
FF access could be granted only after appropriate approvals EVERY time a user needs FF access. Each time a request for the FF role through AE (the request could go through a separate workflow path) and the request will be approved before being provisioned to the user. The approver can change the validity dates on the role assignment so that it can be provisioned for one day, for a week, a month, etc... An audit trail in AE will provide the approver information for historical purposes. This meets the policy of approvals every time FF access is provided instead of the 24/7 master data set-up in the original Firefighter process.
When running an SOD risk analysis on the user, the report will show the SODs the user has including their Firefighter access. (These SODs would then be mitigated per user even though they are a Firefighter.) There is a risk to the company when a firefighter can do one half of the risk on their own user ID and the second half of the risk on their Firefighter ID. Although this could still be caught, it would take some manual analysis. By using role-based Firefighter, all activities are performed and recorded under the user's normal user ID.
The Firefighter does not need to "check-out" a Firefighter ID the access is on their normal user ID.
The standard SAP audit trails have the user IDs instead of the firefighter IDs, so when researching the change, the firefighter logs don't need to be analyzed to see which user had used that Firefighter ID at that time.

GRC 10 Role based firefighter multiple users

Hi All
We are using GRC AC 10 SP12 and have Role based EAM implemented. We are looking at way to prevent the same user from being assigned multiple firefighters or a way for approver to know that another Firefighter ID is already assigned to this user?
Thanks in advance
Regards
Vijaya

Hi Vijaya,
You can train approvers to Click on existing assignment button(in Access Request) to know the roles already assigned.
And if in your environment, FF roles has distinguished naming convention then it can easily be identified
by role owners.
Thanks,
mamoon

EAM ID based or Role based? Why settle for just one?

G'Day All,
I've raised a question in the following blog, however I would like to open it up to other people as well so they might get something out of it and in the process might share their own thoughts on the matter at hand.
ID-Based Firefighting vs. Role-Based Firefighting
So this is where I am at this point:
From what I can gather so far, my understanding of EAM ID/ROLE based is as follows:
- Id Based: Logs in using own U.ID and through GRAC_SPM accesess FFID from the GRC Server and logs into the system assigned to them (ECC, SRM, CRM etc)
Only one user at a time can use a FFID.
Firefighter need not exist in every system assigned to them due to central logon however they need to exist in the GRC system
Knows exactly when FFID is being used as he/she has to login so has a psychological effect (good thing)
Better tracking of FF tasks - Specific log reports with Reason Codes. Bonus point from Auditors!
Two Log ins so potential to commit fraud. (1 action using own UserID and 1 action using FFID)
Could be hard to track and find out when a fraud has been committed so can be a problem with auditors.
      ID Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFIDs assigned to you
      ID Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> You can see the FFIDs assigned to you
- Role Based: Logs into the remote system only using U.ID, so everything gets logged against that one ID.
Multiple users can use the FFROLE at once.
Firefighter has to exist in every system assigned to them - so multiple logons.
Hard to differentiate between FF tasks and normal tasks as no login required So easy to slip up
Time consuming to track FF tasks - No Specific log reports. No Reason Codes
     R.Based -> GRAC_SPM : TCode for Centralised FFighting -> You will see FFROLEs
     R.Based -> /n/GRCPI/GRIA_EAM : TCode for DCentralised FFighting -> Not applicable so wont work
So based on this there are pros and cons in both however according to SAP only one can be used. To me personally, it makes more sense to get the best of both the worlds right? So here is my question why can’t we just use both?
    . Really critical tasks -> FFID
    . Normal EAM tasks -> FFRole
Alessandaro from the original post pointed this out:
"Per design it isn't possible to achieve both types of firefighting at the same time. It's a system limitation and hence to configurable."
Well this is what I can't seem to get my head around. For a FFID, there is a logon session so it has to be enabled and as far as I can tell there is no way around it.
However for FFRole, there isn't such limitations/restrictions like starting a separate session. FFRole is just assigned to an end user for him/her to perform those tasks using their own user ID.
So in what way is it different from any of their other tasks/roles, other than the fact that they've got an Owner/Controller assigned to the FFRole? and
What is stopping us from using it when ID based is the default?
If I were to do the following does it mean I can use both ?
    . Config Parameter: 4000 = 1 (GRC System) -> ID Based
    . Config Parameter: 4000 = 2 (Plug-In) - > Role Based
Please excuse me if my logic is a bit silly, Role Based firefighting is only done on Plug-in systems so the following should work just fine:
   . Config Parameter: 4000 = 2 (Plug-In) - > Role Based
However for ID based, it is a Central Logon, so the following is a must:
    . Config Parameter: 4000 = 1 (GRC System) -> ID Based
Which means both ID/Role based can be used at the same time, which seems to be working just fine on my system. Either way I leave it you experts and I hope you will shed some light on it.
Cheers
Leo..

Gretchen,
Thank you for thoughts on this.
Looks like I'm failing to articulate my thoughts properly as the conversation seems to be going in a different direction from what I am after. I'll try once more!
My query/issue is not in regards to if/what SAP needs to do about this or why there isn't more support from Companies/Organizations and not even, which one is a better option.
My query is what is stopping us(as in the end users ) from using both ID/Role based at the same time?
Now before people start referencing SAP documentation and about parameter 4000, humour me with the following scenario please. Again I would like to reiterate that I am still in the learning phase so my logic might be all wrong/misguided, so please do point out to me where I am going wrong in my thought process as I sincerely would like to know why I am the odd one out in regards to this.
Scenario
I've created the following:
FFID
FFROLE
Assigned them to, two end users
John Doe
Jane Doe
I set the Configuration Parameters as follows:
IMG-> GRC-> AC-> Maintain Configuration Settings -> 4000:1 - ID Based
IMG-> GRC (Plug-in)-> AC-> Maintain Plug-In Configuration Settings-> 4000:2 - Role Based
User1
John Doe logs into his regular backend system (ECCPROD001)-> executes GRAC_SPM-> Enters the GRC system (GRCPROD001)-> Because the parameter is set to ID based in the GRC Box, so he will be able to see the FFID assigned to him-> and will be presented with the logon screen-> Logs in -> Enters the assigned system (lets say CRMPROD001) At this point the firefighting session is under progress
User2
Jane Doe logs into her regular backend system (ECCPROD001) -> (can execute GRAC_SPM to check which FF Role has been assigned to her but she can see that in her regular menu, so there is no point) -> Executes the transactions assigned in FFROLEThis is done at the same time while FFID session is in progress
So all I want to know is if this scenario is possible? if the answer is No, then why not?
I physically carried out this scenario in my system and I had no problems(unless I am really missing the plot here), which brings me back to my original question: Why settle for just one?
Again to reiterate I am not getting into the efficacy or merits of this or even if one should use this. Just want to know if it is possible/feasible or not.
So there you have it. That's the whole enchilada(as they say there in Texas). I tried to word my thoughts as concisely as I can, if there are still any clarifications, more information you or anyone else reading this would like, please do let me know.
Regards,
Leo..

GRC10 Firefighter - Role-based & ID-based

GRC Gurus,
I am looking for a solution or at least theoretical discussion about a scenario in which GRC 10 system is connected to more than 1 target system and in one system I want to use FFID-based option where as in other system it is FF-Role based. For example, in a system where all the users are logging in through SAP GUI, it will be better to have FFID-based firefighter where as in system where most of the users are logging in through portal it will be better to have role-based firefighter. under GRC5.3 it was pretty simple as RTAs were independent in each separate system but in GRC10 since type of firefighter is controlled by single parameter, what will be a way to implement such hybrid approach.
Regards,
Shivraj

Thanks Anji,
Thanks for the response, I am aware of the 4000 situation, I was just wondering if someone has figured out any workaround for this. Because otherwise, it is a step backward for new version as under 5.3, systems could have been on different setups whereas under GRC10 that is not possible.
Regards,
Shivraj Singh

Difference between ID and Role based Administration - Firefighter 5.3

In GRC AC 5.3 Firefighter, security guide, there are two sections for role design,
1. Firefighter Role based Administration
2. Firefighter ID based Administration
Can someone explain what is the difference between the two?
I have read the documentation, but it does not have a clear description of the
differences between the two.
Please help.
Thanks

HI Prakash,
Though both of them eventually achieve the same function, that is giving access rights to the user for a certain period under monitring these differ based on the following:
1. Firefighter Role based Administration
You identlfy a particular role as a firefighter role and give it to the user.
2. Firefighter ID based Administration
You create a separate user altogether and give the normal dialog user, the access to this user's authorization.
For the implication that both of these have and the differences or comparisons between using 1 & 2, I would suggest you do a bit of Mock testing for both of these. Also, there are a lot of posts related to this on the forum already, which you can refer to, for getting a more detailed idea on this topic. Unlimately, it depends on organization to organization which methodology they folow as per what suits them, according to features which both have. But generally what is preferred is Number 2.
Regards,
Hersh.

Renumbering with ACL-Friendly Role-Based Addressing or...?

We are a mid-sized manufacturing firm operating out of three locations and we are in the process of making plans to restructure and renumber our networks so as to better facilitate automated configuration management and security, in addition to easing our deployment of IPv6. Currently, at each site the L3/L2 boundary resides at the network core, but increasing traffic/chatter has us considering moving the L3/L2 boundary to the access layer(s), which consist of 3560-X units in the wiring closets that are supporting edge devices either directly or via 8-port 3560-C compact switches in the further reaches of our manufacturing and warehouse spaces.
As we contemplate moving to a completely routed network, the big unknown we're struggling with is whether or not it is safe or even desirable to abandon ACL-friendly addressing, and whether, in doing so, we can expect to run into hardware limitations resulting from longer ACLs.
Currently, each of our site-wide VLANs gets a subnet of the form 10.x.y.0/24, where x identifies the site and y identifies the class of equipment connected to said VLAN. This allows us to match internal traffic of a given type with just a single ACE, irrespective of where the end-point device resides geographically. Moving L3 routing decisions out to the access switches will require that we adopt smaller prefix assignments, with as many as 8 distinct subnets on each of our standard-issue 3560CG-8PC compact switches. Why so many, you ask? We currently have more than 30 ACL-relevant classifications of devices/hosts - a number that will only grow with time, and to maximize the availability of all services, it is our policy to physically distribute edge devices of a given class (eg. printers, access points, etc) over as many access switches as possible.
From what I can see, we have three options, each of which present trade-offs in terms of management complexity and address utilization efficiency:
Option 1: Stick with ACL-friendly addressing, both for IPv4 and IPv6, and allocate uniform prefixes to each access switch. For IPv4, within the 10.0.0.0/8 block we would probably allocate 8 bits to the site ID (/16), followed by 6 bits as the switch ID (/22), and 7 bits to identify the equipment/host classification (/29), for a maximum of 5 available addresses for a given class of devices on a given access switch. For IPv6, assuming we have a /48 block for each site, we would use the first two bits to identify the type of allocation, the following 6 as the switch ID (/56), and the following 8 as the equipment/host classification (/64).
Option 2: Abandon ACL-friendly addressing and dynamically allocate standard-sized prefixes from a common pool to each VLAN on a given switch. The advantages of this approach are increased utilization efficiency and more addresses available within each VLAN, but it comes at the cost of non-summarizable routing tables and ACLs, and even if the hardware can handle this, it means we're talking about a more complex configuration management system and less ease in troubleshooting problems.
Option 3: Do something similar to option 1, but with the L2/L3 boundary positioned at the distribution layer rather than the access layer. I'm disinclined to go this route, as it seems to require the same, if not more, management complexity than we'll encounter with option 1, with only marginal benefits over keeping things the way they are currently (L2/L3 boundary at the network core).
Thoughts? What issues have we neglected to consider? No matter which approach we select, it shall be assumed that we will be building a system to track all of these prefix assignments, provision switches, and manage their configurations. From a standpoint of routing protocols, we would probably be looking at OSPFv2/v3. It can also be assumed that if we encounter legacy devices requiring direct L2 connectivity to one another that we already have ways of bridging their traffic using external devices, so as far as this discussion is concerned, they aren't an issue.
Thanks in advance for your ideas!
-Aaron

Hi David,
Permissions based on GUI components is a simple & neat idea. But is it rugged? Really secure? It might fall short of Grady Booch's idea of Responsibilities of objects. Also that your Roles and Access components are coupled well with Views!!!!!!!
My suggestion regarding the Management Beans is only to do with the dynamic modification which our discussion was giong forward.
If we go back to our fundamental objective of implementing a Role based access control,let me put some basic questions.
We have taken the roles data from a static XML file during the start up of the container. The Roles or Access are wanted to be changed dynamically during the running of the container. You would scrutinize the changes of Roles and access before permission during the case of dynamic modification.
Do you want this change to happen only for that particular session? Don't you want these changes to persist??? When the container is restarted, don't you want the changes to stay back?
If the answer to the above is YES(yes I want to persist changes), how about doing a write operation(update role/access) of the XML file and continue your operation? After all, you can get the request to a web or session bean and keep going.
If the answer to the above is NO(no, i don't want to persist), you can still get the change role request to a web or session bean and keep going.
Either way, there is going to be an intense scrutiny of the operator before giving her permissions!!!
One hurdle could be that how to get all neighbouring servers know about the changes in roles and access??? An MBean or App Server API could help you in this.
May I request all who see this direction to pour in more comments/ideas ? I would like to hear from David, duffymo, komone and jschell.
Rajesh

Error in Role Based security using weblogic 9

Hi All,
Currently I am working with Weblogic Server 9. I am trying to use role based security. Below is the entries for web.xml.
<security-constraint>
     <web-resource-collection>
          <web-resource-name>Success</web-resource-name>
          <url-pattern>/form.jsp</url-pattern>
          <http-method>GET</http-method>
          <http-method>POST</http-method>
     </web-resource-collection>
     <auth-constraint>
          <role-name>admin</role-name>
     </auth-constraint>
     <user-data-constraint>
<transport-guarantee>INTEGRAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
<login-config>
     <auth-method>BASIC</auth-method>
     <realm-name>myrealm</realm-name>
</login-config>
<security-role>
     <role-name>admin</role-name>
</security-role>
When I am calling form.jsp from the browser it is asking for the username and password, but after giving the username and password it is showing the followig error:
Error 403--Forbidden
From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:
10.4.4 403 Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
So can any one provide me the solution for the above problem.
Thanks in advance.
By,
Sandip Pradhan

Here is a blog post for the backend (WebLogic Admin GUI) http://disaak.blogspot.com/2009/11/migrating-to-weblogic-configure-role.html and a blog post for the web.xml in your project http://disaak.blogspot.com/2009/11/migrating-to-weblogic-configure-ear.html.

Role-Based CLI Views with AAA method

Hi,
I'm configuring Role-Based CLI Views on a router for limiting access to users.
My criteria:
- There should be a local user account on the router that has the view 'service' attached to it
- If the router is online and can reach the radius server, people in the correct group are assigned the view 'service'
My configuration:
aaa new-model
enable secret 1234
username service view service secret 1234
aaa group server radius my_radius
server-private 10.1.1.1 auth-port 1645 acct-port 1646 timeout 3 retransmit 2 key 0 1234
server-private 10.1.1.2 auth-port 1645 acct-port 1646 timeout 2 retransmit 1 key 0 1234
aaa authorization console
aaa authentication login mgmt group my_radius local
aaa authorization exec mgmt group my_radius local
line con 0
authorization exec mgmt
logging synchronous
login authentication mgmt
line vty 0 4
authorization exec mgmt
logging synchronous
login authentication mgmt
transport input ssh
The ERROR
Now I want to go configure the cli view 'service'...
# enable view
Password: 1234
*Jun 1 08:00:02.991: AAA/AUTHEN/VIEW (0000000D): Pick method list 'mgmt'
*Jun 1 08:00:02.991: RADIUS/ENCODE(0000000D): ask "Password: "
*Jun 1 08:00:02.991: RADIUS/ENCODE(0000000D): send packet; GET_PASSWORD
*Jun 1 08:00:21.011: RADIUS: Received from id 1645/13 10.1.1.1:1645, Access-Reject, len 20
The Questions
Why does the 'enable view' try to pick a method list when you have to supply the enable secret to access the root view?
Can you change this behaviour to always use the enable secret?
The TEMP Solution
If you're logged on to the router via telnet or SSH, the solution or workaround to this issue is:
aaa authentication login VIEW_CONFG local
line vty 0 4
login authentication VIEW_CONFG
Do your configuration of the view and re-configure the line to use the correct (wanted) method of authentication.
Thanks so much for the suggestions
/JZN

hi,
You have the following configured:
aaa authentication login mgmt group my_radius local
aaa authorization exec mgmt group my_radius local
line con 0
authorization exec mgmt
logging synchronous
login authentication mgmt
line vty 0 4
authorization exec mgmt
logging synchronous
login authentication mgmt
transport input ssh
Hence every time you try to login to the console or try the ssh the authentication will head to the radius server because of the following command "login authentication mgmt".
You cannot make it locally. Whatever defined on the method list mgmt first will be taking the precedence.
enable seceret will be locally defined. but you have the following configured:
aaa authorization exec mgmt group my_radius local
line con 0
authorization exec mgmt
line vty 0 4
authorization exec mgmt
Hence exec mode will also be done via radius server.
when you configure:
aaa authentication login VIEW_CONFG local
line vty 0 4
login authentication VIEW_CONFG
You are making the authentication local, hence it is working the way you want.
In short, whatever authentication is defined 1st on the method list will take precendence. the fallback will be checked only if the 1st aaa server is not reachable.
Hope this helps.
Regards,
Anisha
P.S.: please mark this thread as answered if you feel your query is resolved. Do rate helpful posts.

IManager error editing Role Based Entitilements

Hi,
A while back we had to re-create our Organisational CA and server certificates. (Don't ask why...) Everything seemed to go well except for one issue I've been having since.
We have OES2 SP3 (eDir 8.8 SP6) running on SLES 10 SP3.
iManager version is 2.7.4
Identity Manager Version is 3.6.1
When I try to edit a role based entitlement I get the error:
"Unable to obtain an LDAP context. Possible causes: the LDAP server is not running, or the LDAP server is for a tree other than the one iManager was originally set up for, and SSL has not been set up between the iManager server and the LDAP server. Either start the LDAP server, or set up SSL by importing a trusted certificate. "
I have tried deleting the iMKS file and importing the certificate manually as detailed here:
https://www.novell.com/documentation...a/bx8g5g8.html
There are plenty of other pages showing the same method of resolving this issue but none have worked.
Any ideas?
Thanks.

Hi,
A while back we had to re-create our Organisational CA and server certificates. (Don't ask why...) Everything seemed to go well except for one issue I've been having since.
We have OES2 SP3 (eDir 8.8 SP6) running on SLES 10 SP3.
iManager version is 2.7.4
Identity Manager Version is 3.6.1
When I try to edit a role based entitlement I get the error:
"Unable to obtain an LDAP context. Possible causes: the LDAP server is not running, or the LDAP server is for a tree other than the one iManager was originally set up for, and SSL has not been set up between the iManager server and the LDAP server. Either start the LDAP server, or set up SSL by importing a trusted certificate. "
I have tried deleting the iMKS file and importing the certificate manually as detailed here:
https://www.novell.com/documentation...a/bx8g5g8.html
There are plenty of other pages showing the same method of resolving this issue but none have worked.
Any ideas?
Thanks.

IManager & Role Based Entitlements

I'm re-posting this here as I didn't get any response from the original post linked below:
https://forums.novell.com/showthread...-Entitilements
Hi,
A while back we had to re-create our Organisational CA and server certificates. (Don't ask why...) Everything seemed to go well except for one issue I've been having since.
We have OES2 SP3 (eDir 8.8 SP6) running on SLES 10 SP3.
iManager version is 2.7.4
Identity Manager Version is 3.6.1
When I try to edit a role based entitlement I get the error:
"Unable to obtain an LDAP context. Possible causes: the LDAP server is not running, or the LDAP server is for a tree other than the one iManager was originally set up for, and SSL has not been set up between the iManager server and the LDAP server. Either start the LDAP server, or set up SSL by importing a trusted certificate. "
I have tried deleting the iMKS file and importing the certificate manually as detailed here:
https://www.novell.com/documentation...a/bx8g5g8.html
There are plenty of other pages showing the same method of resolving this issue but none have worked.
Any ideas?
Thanks.

For some reason I cannot find your old post via NNTP, though I see it on
the web interface. Perhaps the gateway had a problem, which would have
limited your responses. Either way, for future reference, you may want to
post questions on the RBE features in the iManager or IDM forums, both
located on https://forums.netiq.com/ (same looking page, same account,
just focused on the NetIQ products, including those moved over from
Novell). Also, for iManager problems, same thing: try the iManager forum
specifically on the NetIQ site. Considering you've been with Novell for a
while, it's definitely understandable that you'd look here for those
forums, though, as they used to be on this site.
The vast majority of iManager functions use NCP exclusively; adding users,
modifying them, associating with groups, setting up file services
(CIFS/SMB/AFP/NSS), managing most of IDM, configuring LDAP services
provided by eDirectory, etc.. eDirectory, after all, is NCP-based and
LDAP is an interface added to it to do things that work better via LDAP.
Thus, most things work just fine no matter what you do via LDAP.
In your case you are describing one of the few services where iManager
actually needs to work with eDirectory via LDAP. Other examples including
working with Universal Password (UP) under the Passwords role. In these
cases iManager uses eDirectory to find appropriate LDAP services and then
connects to those as well for specific operations. As a result, we look
at LDAP as it sounds like you have already done. TID# 7008836 seems to
have very similar instructions to the documentation link you posted, but
you may find it useful in some way.
You mentioned recreating your CA and server certificates (Key Material
Objects, or KMOs). Doing this SHOULD have made it so all certificates you
created (presumably after the CA change) would be minted by the new CA, so
if you browse to those certificates you should see them with a Trusted
Root of the new CA, which should have (by default) an expiration ten years
from its creation (individual KMOs expire by default two years after
creation). With this verified, your LDAP Server object (for which there
is usually one per NCP/eDirectory server) will also have a link to one
KMO. If you did not delete old certificates, it is very possible that the
LDAP Server is still pointed to an old KMO and using it happily even
though the rest of the tree is using new data, and the old KMO may be
expired causing issues with clients (like iManager). Be sure to check
that. If pointed to an old KMO, point it to a new one and then restart
eDirectory (or maybe just the LDAP module).
Other things you may try include setting up iManager Workstation 2.7 SP7;
it runs on your workstation and then otherwise acts like the server in
most areas. Getting old IDM 3.6.1 plugins on there may be the hardest
part, but really should not be that hard if you have the IDM media
somewhere. With this you can test pointing to your enviornment to see if
anything works there, ruling in/out a weird iManager problem.
Also, is it safe to assume that eDirectory 8.8 SP6 is the latest version
in your tree? If 8.8 SP8 exists there is a change in LDAP configuration
data, specifically the ldapInterfaces attribute on the LDAP Server object,
which can cause LDAP-using plugins to have a hard time finding 8.8 SP8
servers specifically.
Lastly, especially if you have iManager Workstation or if you have
iManager on a non-eDirectory box, getting a LAN trace could help us see
exactly what iManager is doing on the wire, and then isolate better why it
is failing.
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

Weblogic security & EJB role based access

How does (or not) weblogic security tie into the EJB notion of role based
control ? Can we create a 'custom' security mechanism for EJB (which
basically uses the EJB facilities but extends it within the application) by
using custom weblogic realms ?
Thanks
Raju

Thanks !
"Terry" <[email protected]> wrote in message
news:[email protected]...
comments inline
r <[email protected]> wrote in message
news:[email protected]...
>>
Here are some more specific questions around an 'example' scenario:
The application has an entity bean 'Account' that can be accessed by the
roles 'Bank Employee' and 'Customer'
'Bank Employee' can execute the 'getBalance()' and 'placeOnHold()'
methods on the 'Account' bean
'Customer' can execute the 'withdraw()', 'deposit()', and'getBalance()'
methods on the 'Account' bean
These permissions are set up through the deployment descriptor by
mapping
the 'Bank Employee' and 'Customer' roles
to the particular bean methods that the role should be given access to.
1. How does weblogic provide the facility to map the EJB deployment
descriptor
<security-role> to a particular weblogic principal (user orgroup)
Or, should I say, how do I map the user or group to a
deployment-descriptor defined role?In the deployment tool, once in the jar select the 'Security' item,create
an application role (in your case it is probably best to create 2 security
roles - the bank employee role refering to the bank employee group (usethe
'in role' checkboxes, and the customer role refering to the customergroup -
there may at some point be use for an allUsers role, which includes both
groups, maybe not. What I am saying is that a role is made of a one ormore
of Principals - in our case groups)
In the Account Bean select the method permissions item, and create amethod
permission perm-0, select the perm-0 item that has just popped up in the
left hand window, tick the box for placeOnHold(), and the boxes for<remote>
and <home> one level deeper than this in the tree (as an aside, I have
absolutely no idea why there would be a 'home' box here, ho hum). Selectthe
'bank employee' 'can invoke' tickbox
Create perm-1, and do what you did above for 'withdraw()' and 'deposit()'
methods, and the 'customer' tickbox
I believe the documents say you would have to set up another permission to
allow both groups access to the getBalance method, but in practive Ihaven't
found this the case.
The documentation for this is at
http://www.weblogic.com/docs51/classdocs/API_ejb/EJB_deploy.html#1102211
(or
search for 'Deploying EJBs with DeployerTool'
2. Are there any administrative tools provided by weblogic to do
this
mapping ?The deployer tool. Otherwise I think it's the acse of writing your own xml
files
3. How much effort & complexity is involved in creating a custom
realm
Hmmm, depends - you could have the RDBMSRealm that is provided in'examples'
in half an hour or so (there is a problem with one of the RDBMSUser's
methods - getUserType or something like that - the solution can be foundin
the newsgroups if you search), the same is probably true of the LDAPRealm,
NTRealm etc (although I have never used these).
Which one you choose depends on what equipment you have available,although
I would say that the RDBMSRealm canuse a lot of optimisation
Thanks,Welcome
Raju
"Terry" <[email protected]> wrote in message
news:[email protected]...
The Principals (i.e. groups and users) from your custom realm are used
to
define application roles for the EJBs, but, as far as I am aware youcannot
use a custom implementation for the ACLs for EJBs
terry
r <[email protected]> wrote in message
news:[email protected]...
How does (or not) weblogic security tie into the EJB notion of rolebased
control ? Can we create a 'custom' security mechanism for EJB (which
basically uses the EJB facilities but extends it within the
application)
by
using custom weblogic realms ?
Thanks
Raju

Custom security JHeadstart 11gTP1 -Use Role-based Authorization is missing

In JHeadstart 11g TP1 the option Use Role-based Authorization is missing.
Will this option only be available in de production release of JHeadstart 11g? What is the reason why this is missing? Is it still possible to use CUSTOM authorization in JHeadstart 11g TP1?

It is not missing.
If you turn on custom authorization, you can specify your own roles against groups to access them, and use role names in the insert allowed/update allowed and delete allowed expressions.
Steven Davelaar,
JHeadstart Team.

Why Role based Firefighter

Similar Messages

Maybe you are looking for