On 9/3/2009 4:16 PM, mojo2000 wrote:
> The admin user doesn't have the rights to login. I get the error message
> "Account restrictions prevent you from logging in. See your
> administrator for more details." (please see attached image)
> At the time of the User App installation for JBoss I have designated
> him as the administrator.
> |Filename: Screen shot 2009-09-03 at 2.59.35 PM.png |
> |Download: http://forums.novell.com/attachment.php?attachmentid=3343 |
Here is my article submitted to Cool Solutions on one possible cause for
your issue. Without trace from when it happened it is kind of hard to
User App roles failing to apply for Administrators:
With the release of Novell's Role Based Provisioning Module (RBPM)
version 3.7 there was a new driver added, the Roles and Resources
driver. This is actually a newer version of the Roles driver that the
Identity Manager 3.6.1 RBPM module used, but still it is a different driver.
What is also newer in the RBPM 3.7 and RBPM 4.0 since the IDM 4 Roles
Based Provisioning Module is basically an updated and tweaked RBPM 3.7
is how much the User Application relies on the Roles and Services
driver. Basically the request is made to grant a Role or access to a
Resource it actually creates an object that has all the request
information in it. These are stored in the ReqDef container under the
AppConfig container, which is stored inside the User Application IDM
driver. The IDM driver for User Application is used for a couple of
things, but one of the main reasons it has to be deployed before you
start the User Application web application, is that the configuration
information for the web application is stored and retrieved from the
AppConfig container, which is created inside the Driver object.
Basically at the simplest level, you need somewhere to put the
information, and by deciding to store it in the driver object and
requiring the driver object to be created, you solve the chicken and egg
problem for getting started. This decides it is the Egg that must be
created first, then the chicken will read it and populate it with
information. Ok that metaphor was a bit strained, but you get the idea.
The Roles and Services driver events on this object create (and I think
polls periodically as well) and tries to process the Role or Resource
request as it receives them. I know it polls for certain events,
because you can put a begin and end date on a Request, and therefore
every heartbeat or so, the driver will go looking for any Requests that
have either become valid or expired since the last poll and process
them. What I do not know is if it will catch an unprocessed request at
that point. I suppose if the start date is in the past and it is
unprocessed the query ought to find it, just like it would be if the
driver had been turned off for a while.
In fact even the Roles that define access to the User Application roles
themselves are granted this way. What that means is, during
configupdate.sh, you can assign all the Roles to one user (by specifying
the same LDAP DN of the user for all the different security roles that
are listed) or you can choose individual users.
The Roles are:
RBPM Configuration Administrator
IDM 4 has a Reporting Administrator as well and possibly one more Role.
As it turns out, there are a couple of cases where you need to be two
Roles at least to do something, and if you do not have any single user
with both of those Roles it is a pain to fix that, without a single user
having sufficient rights. If you wanted to grant the Resource Role to
someone else you need to go in as a Role Administrator grant the Role
Admin right to a Resource Admin then that Resource Admin (who is also a
Role Admin) can now grant the Resource role to someone else. Very
annoying the first time, but once you have a couple of users set up it
is not a problem. Additionally the Roles Mapping Administrator utility
in IDM 4 runs through the User Application's security model, and
therefore requires that any one using it have Roles and Resources
Administrator rights before they can do much of anything in it. This
makes some kind of sense since they will be defining Resources or Roles
in the process of using the RMA tool.
Interestingly enough, the Role requests are not issued when you would
expect. It is not the first time you start Jboss, nor the first time
you login to the User Application. Rather the Role Requests are issued
the first time a web browser requests the JBoss server to display any of
the User Application user interface (like the login page) which requires
JBoss to unpack and instantiate the IDMProv.war file. This is the key
event. Which is somewhat surprising to me, I would have expected either
of the two times I suggested at the beginning of this paragraph.
Different strokes for different folks I guess.
Granting all the rights to one user or each right to a separate user is
usually just an issue at first, so I now take to following John
DaSilva's advice and make your User App Admin user the Domain
administrator for all the various things, then later grant the specific
rights to specific users. It just makes things much easier across the
As it turns out the User Application Administrator account is stored in
the User Application database, and the first one granted cannot be
deleted, though additional ones can be added. This is NOT processed via
the Roles model, but is rather set via configupdate.sh.
These two sets of rights, the User Application Administrator, and a
bunch of domain administrators Roles (7 or more) and they are
independent and annoying to fix if you are missing any.
There is a very common case where the Roles you set up in
configupdate.sh are just plain not set. There are actually a couple of
issues that work together to cause this problem, and of course they can
be a problem independent of each, which just makes it even better.
There are two main root causes:
1) Not enough memory when you first run UA in Jboss (start-jboss.sh)
causes it to die midway through issuing roles.
2) Designer bug with the first GCV of type DN not working. Check the
Roles and Services Driver, driver config, for the User container. It
probably has the User App DN not the ou=users,dc=test,dc=com
For whatever reason, the JBoss installation that comes with Novell
Identity Manager, defaults (or did default) to use 256 MB of Java heap.
In theory this used to be enough, but with the RBPM module my
experience is that most times, on startup of the User Application it
will run out of memory midway through issuing the security roles. This
is a lousy situation to be in, since they are issued, but not
completely, leaving to bizarre results. I have a trace from the server
of this happening, and was lucky I caught it, otherwise I would have had
no clue why some stuff was working and others were not.
The server.log from your JBoss will show a long series of events
something like this one, as it issues the Role Request.
2010-09-16 12:31:21,761 INFO
[Role_Request] Requested by cn=admin,ou=admins,o=acme,dc=com, Target DN:
Application,cn=IDM,ou=Drivers,o=acme,dc=com, Request Category: 10,
Request Status: 0, Original Request Status: 0, Correlation ID:
You can see a number of things from this request, and it is worth
picking apart to better understand. It is tagged [Role_Request] which
makes it easier to find in trace. (Which is why I paste it into this
article so the Google cache will be able to find that string!) Note the
requestor is there, the target objects DN (who is getting the Role) is
listed, the Role DN is listed as the Source DN for some reason, which
you can see is buried in the AppConfig container under the User
Application driver container.
What is more interesting to me, is you can see the Request DN, that is
the object that holds the request so you can go look at it. You will
see dozens of these requests generated the first time. If you do not
have enough Java heap for JBoss then it will die midway through the process.
The second error is even stranger. I have seen other people report it,
but none of us seem able to reliably reproduce it to get Novell to fix
it. If you have a way to reproduce it report it. Anyway, there seems
to be something wrong with how the Designer history for DN configuration
attributes works. It seems to only affect the first item on each page
in Designer (and not all of them, which is so frustrating!) I have seen
it with Global Configuration Variables (GCV) before, and this time it is
on the Driver Configuration page. The first item on the page is the
User Container. This should be something like ou=Users,o=idv, and you
probably even typed it! However Designer for some reason decided to set
it to the value of the User Application drivers DN. If you start typing
in the field you will see it jumps to some somewhat strange values in
the history buffer and won't accept much else.
When it is a GCV, what I usually do is change the GCV type from DN to
string, and just type the right value. When it is a Driver
Configuration value, you are not supposed to directly edit them, but the
good news is you can click on the Edit XML button and just edit the
underlying XML. Change the type='dn' to type='string' and you should be
fine after that.
It is quite annoying, and trivial to fix, once you know it is about to
happen. I wish I could force it to happen on demand, so I could report
it to get fixed.
The reason this matters, is that the Roles and Services driver will see
the Role requests issued, if you had just fixed the first problem, look
at the Target DN, say, oh that user object is not in the User
Application driver container (the nonsense value Designer has
erroneously added to the value) and declare it out of scope. So the
rights get requested, and then ignored. By fixing this setting you can
then get the Roles and Services driver to work and process such requests.
Now once you fix these two issues, you are still goofed up, since the
User Application only ever happens at the first time the WAR is
unpacked. This is somewhere a button in the User Application to do it
would be helpful, and once you read the steps you need to take to fix
it, you will see why I say that!
The steps are all documented in the docs, (Section 2.13 of the User App
For IDM 4 (which is the same exact approach as in RBPM 3.7) check this
You need to find the Configuration object, that is in the AppDefs
container, under the AppConfig container, which is where the User
Application configuration information is stored inside the User App
Driver object. The docs describe it as:
%DriverSet% -> %userApplication Driver% -> AppConfig -> AppDefs ->
You need to look at the XMLData attribute, which is a very long XML blob
of data, and look for the entry:
Then you need to delete this node of data. This is what tells the User
Application that it has issued the first rights grants, and what is
preventing it from doing it again. Not the entire XMLData attribute,
just the one small nodeset within it. I have used Console1 and an LDAP
browser to do this. Both work, and iManager should work as well. It is
usually easier to copy the entire text into a real text editor, find the
node, delete it (from <property> to </property>) and then paste the text
back in. But whatever way you want to approach it should work.
Now the docs say you need to have JBoss stopped, the driver stopped,
wave a chicken over your head. But in my experience it is sufficient to
just restart JBoss after doing this change.
Next time you hit the WAR file with a web browser after a JBoss start,
and the WAR unpacks itself, it will issue the roles again. Then you
should be able to login as one of the users you assigned and see the
appropriate set of Roles.
This is one of those really annoying things to fix, as until you update
the Configuration object's XMLData attribute by remove the
domain-admin.initialized setting, no matter what you do in
configupdate.sh will not make a smidgen of a difference. Personally I
think, if the data in configupdate.sh is changed, then the User
Application should reinitialize the roles again by default to save all
the pain of this process.