The DCE Security Server contains Security and authentication services. This section contains security troubleshooting information. For additional security troubleshooting procedures, see IBM DCE for AIX, Version 2.2: Administration Guide--Core Components.
To give permission for principals in other cells to engage in authenticated access to objects in your cell, you must establish a trust relationship with that cell. Use the dcecp registry connect cell command.
| Note: | This command must be done only once, in one of the cells, though the cell administrator's password must be valid in both cells. |
This creates a principal and account in each cell registry of the form:
krbtgt/<foreign_cell_name>
These entries can be viewed using dcecp. If either cell is reconfigured, the krbtgt entry in the foreign cell must be deleted and the trust relationship established again.
Initialization (init_secval_data) failed.
status=0x113db0ed
This problem is created by incorrect permissions on /opt/dcelocal/var/security/preauth directory. Correct permissions look like:
94 drwx--x--x 2 root system 512 Oct 17 15:41 preauth
The default for the Security Server (secd) checkpoint interval, which is the interval for secd to flush its update log to disk, is two hours. To change this interval, start secd from the command line with the -cpi option.
secd -cpi 300
where the interval is in seconds. This command starts secd with a checkpoint interval of five minutes. Force a checkpoint by using dcecp registry checkpoint. This works on both the Replica Security Server and the Master.
This error usually means that secd is in maintenance mode. To see the state of the secd use sec_admin, enter
sec_admin> info -full
This shows that the state is in maintenance, rather than in service. Enter:
sec_admin> state -s
to get it back into service mode.
If you get a password invalid message and you are sure you are using the correct password, check for clock skew. To get the time on an AIX machine, issue the date command. Make sure that you do not set the clocks backwards. If the clocks on the client you are trying to log in to and the secd server machine are more than five minutes apart, enter the command:
setclock hostname_of_server_machine
on the client to synchronize the clocks.
If you have set your password policy to expire at a certain time or have set the password lifetime to a specific value, you must be aware that the secd principal, self principals for hosts, and the cell_admin principal is also bound to this limit.
The recommended model is to set the policy to forever. Add granularity through lifetimes on organization and individual accounts. The critical principals in your cell should not have their passwords expire unexpectedly.
If you have a problem that you cannot start DCE due to a password expiration problem, you must start secd up in locksmith mode and change the password policy. Remember secd starts in the foreground in locksmith mode.
secd -locksmith cell_admin -remote
Use rgy_edit from another window to change the password lifetime.
rgy_edit> po
Policy:
Account lifespan: forever
Password min len: 0
Password lifespan: 12w6d
Password expiration date: 1997/10/28.23:00
Passwords MAY be all spaces, MAY be all alphanumeric
Do you wish to make changes [y/n]? (n) y
Enter acct lifespan in days or 'forever': (forever)
Enter minimum password length: (0)
Enter password lifespan in days or 'forever': (12w6d) forever
Enter password expiration date [yy/mm/dd or 'none']: (1997/10/28.23:00) none
May passwords be all spaces [y/n]? (yes)
May passwords be all alphanumeric [y/n]? (yes)
rgy_edit=>
The pe_site file can be used for Security Server load balancing and, if CDS is down, it can be used to locate a Security Server. Use the BIND_PE_SITE=1 environment variable to enable this functionality. Alternatively, use the TRY_PE_SITE=1 environment variable. The TRY_PE_SITE variable tries each binding in the pe_site file and then tries CDS for a binding. You can rebuild the pe_site file with the chpesite command.
The dce-ptgt principal in the registry defaults to two hours. If the maximum ticket lifetime for this principal is changed, all service tickets then get the new value for the maximum ticket lifetime of the dce-ptgt principal. This helps with GSSAPI APIs that fail with the error sec_priv_s_deleg_token_exp, which means the delegation token has expired.
Using replication and making updates in quick succession produces this error. The propagation takes a few seconds to complete. If you make an update and immediately try to access data depending on the update (for example, you create a group and then try to create an account based on the group) you may bind to the replica that does not yet have the update. Wait until the update is propagated or bind to the Master to solve the problem.
When both the Master and Replica are up and running, and you want to designate the Replica to be the Master, follow this procedure. Note that CDS must be functional in order for the update to occur.
dcecp -c registry designate /.:/subsys/dce/sec/master -slave dcecp -c registry designate /.:/subsys/dce/sec/replica_name -master
The sec_acl_test_on_behalf API is no longer implemented. The new model is to use delegation.
There is a limit of 1024 characters to a principal name. A principal name includes the cell name.
If you have a large user base that you need to populate your security registry with, there are a few issues to keep in mind. First, updates to the security database are kept in memory in an update_log until checkpoint to disk. Each account added uses about 2.5 KB memory per account and each account uses about 1KB of disk space. You must to checkpoint secd frequently to avoid using up all your available memory. secd may hit the AIX process size limit of 135 KB. To increase this limit, you can use the large memory model and issue the following command to get up to two GB:
/usr/bin/echo '\0200\0\0\0'|dd of=executable_file_name bs=4 count=1 seek=19 conv=notrunc
passwd_export
The DCE passwd_export command updates the local AIX password files from the DCE registry data. The passwd_export command does not create or make additions or changes to the /etc/security/passwd or /etc/security/group files. This means encrypted passwords are not put into /etc/security/passwd
The tool has been designed by OSF to put passwords into /etc/passwd. If the "hidden password" property in passwd_export is set to off, the encrypted passwords are stored in /etc/passwd; if set to on, you see an asterisk (*) or a bang (!) in the password field.
passwd_import
The DCE passwd_import command creates DCE registry entries based on information in the local AIX password file, /etc/passwd. The defaults for the accounts created in the registry by passwd_import include:
account_valid = false passwd_valid = false password randomly generated
Any of the these commands prevent you from logging in to the account if it has been created.
The passwords are randomly generated. You must modify or reset randomly generated passwords before user authentication or login is possible.
The DCE rdacl interface does not support user and group owner objects. Anyone developing an ACL manager using the DCE rdacl interface should not set the dce_acl_c_has_owner and dce_acl_c_has_groups flags when issuing the dce_acl_register_object_type API.
dce_acl_inq_prin_and_group does not return the principal and group owner of an object. dce_acl_inq_prin_and_group calls sec_cred_get_pa_data, which returns the principal and primary group of the client that made the call. It does not return the principal and group owner of an object.
The only process that recognizes the owners for an object is the ACL manager. The problem is the way the DCE rdacl interface is set up; the only way an ACL manager can pass this information to the DCE rdacl interface is through the dce_acl_register_object_type API resolver function. Unfortunately, the interface for the resolver function has only one output field, for the ACL UUID. It does not have additional output fields for the ACL manager to use in returning the principal owner and group owner the object.
This problem cannot be addressed yet in the AIX DCE code because of interoperability issues with other vendor platform DCE products.