David,

This problem is caused by the pam.conf configuration.

Th PAM module pam_tsol_accounts checks whether the current process label 
is within the range for the user or role being authenticated. When a 
role is assumed via the Trusted Path, this PAM module is running with a 
process label of ADMIN_HIGH, so it is rejecting a role whose label range 
doesn't include ADMIN_HIGH.

Since you have all the recent patches, you can now workaround this 
problem by adding a new PAM stack for tsoljds-tstripe with the same two 
lines that are associated with dtsession.

You might remember that one of the regressions that we has in S10 update 
4 that I wrote about in my blog related to nscd. That problem affected 
the PAM module pam_unix_account, which does password aging. This wasn't 
working so, the workaround we applied then was to remove 
pam_unix_account, but we still needed to have at least one PAM module to 
return PAM_SUCCESS, which was done by pam_tsol_accounts.

Now that the nscd bug has been fixed in a patch, the stack entries for 
dtsession and tsoljds-tstripe should look like this:

dtsession  account requisite pam_roles.so.1
dtsession  account required pam_unix_account.so.1

tsoljds-tstripe account requisite pam_roles.so.1
tsoljds-tstripe account required pam_unix_account.so.1

Once pam_tsol_account is removed, your roles no longer need to be 
cleared for all labels.

--Glenn

David Gaines wrote:
> I'm using Solaris 10 TX 8/07 with Directory Server 5.2 p6, SRSS 4.0 update 2, 
> and several thick clients.  The DS, SRSS, and NFS server reside on different 
> hardware.  The patches are current on all systems as of 8 Jan 08.  I have 
> encountered a problem with roles when users are in TJDS.  I've created a role 
> in LDAP with no rights or privileges other than what is in the default 
> policy.conf.  This role will allow select users to run Win4Solaris.  I do not 
> want these users to have access to admin_low or admin_high so they are not 
> part of the role.  This arrangement works in TCDE without a problem.  
> However, when a user tries to assume the role in TJDS they receive the 
> following error message. " The system administrator has temporarily disabled 
> access to the system for <role name>. See your system administrator."  This 
> problem exists on thick and thin clients.  If I edit the role to add 
> admin_low and admin_high the problem goes away if I remove admin_low and 
> admin_high the probl!
 em 
>  returns.  Is anyone aware of this problem?
>  
>  
> This message posted from opensolaris.org
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
>   



Reply via email to