Three reasons why a home directory might not be created are: inability to communicate with the server; no authorizations to write to that server; or the administrator cannot be authenticated by the home directory server.
Typical error messages include:
The attempt to add [or modify] the Home
Directory name for User name on Server name has failed.
Access was denied, while attempting to add a
Home Dir.
Lack of Communication With Server
When you add a new user, you must specify the name of the server on which the user's home directory is located. If User Accounts cannot contact that machine, you are notified that the user was added but the home directory could not be created. (This problem occurs only when adding a user to a name service domain, not to a single machine.)
Possible reasons why the home directory was not created: you may have mistyped the server name in the wizard, the server might be temporarily out of service, or the Solaris Management Console server is not running.
To create the user's home directory after you have added the user, be sure the console server is running on the machine where the home directory is to be created. Then:
In User Accounts, double-click the user's name.
In the User Properties dialog box, click the Home Directory tab.
In the Home Directory Server field, type the server name. Note: This field is writable only until the directory is created. Once the directory is created, the server name cannot be changed.
Not Authorized on Home Directory Server
When you add a new user, in order to create the user's home directory on the remote server, you must be authorized to write to that server.
Request that your administrator include in your granted rights the authorization to write to the home directory server of the user being added. This requires an account on that server, or an account in the domain where that server is located, and the User Management, User Security, Primary Administrator, or System Administrator right. Then type the server name into the Home Directory tab of the Properties dialog box of the user who was added.
Three reasons why a mailbox might not be created are: inability to communicate with the mail server; no authorization to write to that server; or the administrator cannot be authenticated by the mail server.
Typical error messages include:
Access was denied while attempting to add [modify] Mailbox for
user: username
.
The attempt to add [modify] the Mailbox for User name on
Server name has failed.
Lack of Communication With Server
When you add a new user, you must specify the name of the server on which the user's mailbox is to be located. (The mailbox is the file that contains the user's newly received email.) If User Accounts cannot contact that server, you are notified that the user was added but the mailbox could not be created. (This problem occurs only when adding a user to a name service domain, not to a single server.)
Possible reasons why the mailbox was not created: you may have mistyped the server name in the wizard, the mail server might be temporarily out of service, or the Solaris Management Console server is not running on the remote home directory machine.
To create the user's mailbox after you have added the user, be sure the console server is running on the mail server, then:
In User Accounts, double-click the user's name.
In the User Properties dialog box, click the Mail tab.
In the Mail Server field, type the server name.
Note: This field is writable only until the mailbox is created. Once the mailbox is created, the server name cannot be changed.
Not Authorized on Mail Server
When you add a new user, in order to create the user's mailbox on the remote server, you must be authorized to write to that server.
Request that your administrator include in your granted rights the authorization to write to the mail server of the user being added. This requires an account on that server, or an account in the domain where that server is located, and the User Management, User Security, Primary Administrator, or System Administrator right. Then, open the Properties dialog box of the user and type the server name into the Mail tab.
An administrator is unable to create the home directory or mailbox for a user because the home directory or mailbox server is unable to authenticate the administrator.
The error message states:
Could not connect to server: The management server cannot
authenticate your identity. Be sure your user name and password are
correct, and try again.
Problem: The administrator's user account does not
exist in the passwd
table used by the home directory or
mailbox server. (If mail servers or home directory servers are
located in a domain other than the one in which User Manager is
located, then separate accounts need to be set up in that domain for
administrators responsible for adding users.)
Solution: Make sure the administrator is added to
the passwd
table on the home directory server or mailbox
server. Create a duplicate of the administrator's account (with the
rights to administer users) on the appropriate server.
Problem: The Solaris Management Console is searching
the wrong passwd
file or table for authentication information.
Solution: Make sure settings in the /etc/nsswitch.conf
file are configured for the way you want authentication
information to be found.
To see whether the console server is running: as the root
user, type /etc/init.d/init.wbem status
To stop and start the console server: as the root
user,
type /etc/init.d/init.wbem stop
then /etc/init.d/init.wbem
start
You may need to change the domain or server location where authentication information for a specific user or role is stored. But, before changing any authentication settings, be sure you know what server is being addressed for authentication.
Authentication information is contained in the /etc/passwd
file on a single server, or in the corresponding password
table of a name service domain. The /etc/nsswitch.conf
file provides a search order for finding (among other things)
authentication information about users who log in to the Solaris Management Console.
The line passwd:
followed by, for example, files
nis nisplus
specifies the search order to begin with files,
looking for a specific user to authenticate, and then proceed to the
NIS and NIS+ domains. It uses the first password entry
with information about the user being authenticated.
Determine which server you are trying to manage.
Look in the toolbox editor (run /usr/sadm/bin/smc edit
)
to determine the server associated with a specific tool. The editor
provides the names of the computer (hosts), server, and domain
associated with each tool.
Determine the name of the domain and the master server.
On the server machine where the authentication is failing (for example, the home directory server):
For an NIS domain, enter more /etc/defaultdomain
to
determine the domain and ypwhich -m passwd
for the
master server name.
For NIS+ domain and master server information enter niscat -o passwd.org_dir
.
See if it is necessary to change the password
file
used.
Look in the /etc/nsswitch.conf
file for the passwd:
search order.
Change this search order only if necessary, for example if an administrator's password file is in local files, but you want it to be on an NIS server.
Note: Changing the search order affects ALL commands and
applications on the machine that perform lookups in the passwd
table. It also affects the order in which passwd
tables
are searched for login
and rlogin
.
There are numerous reasons why a management server might be unable to authenticate the identity of a user (verify the user's identity by checking the user's name against the password).
Problem: The password entered by the user is incorrect.
Solution: Check the password and re-enter it.
Problem: The user account is locked, preventing the user from logging in.
Solution: An administrator with the right to manage passwords must open the user's Properties dialog box in User Accounts. On the General tab, unlock the account by selecting Account is Always Available or Account is Available Until (and enter a date).
Problem: The user account does not have a password assigned to it.
Solution: An administrator with the right to manage passwords must open the user's Properties dialog box in User Accounts. On the Password tab, select User Must Set Password At Next Login (and the user must log in to the Solaris operating environment first, to set the password), or User Must Use This Password At Next Login (and inform the user of the password).
Problem: The user account does not exist in the /etc/passwd
file used by the server for user logins in this domain.
Solution: Make sure the user is added to the /etc/passwd
file on the server that is providing the authentication. Through User
Accounts, add the user account to the appropriate server.
Problem: The Solaris Management Console is searching
in the wrong passwd
file or table for this user's
information because of incorrect settings in the /etc/nsswitch.conf
file on the remote server.
Solution: Make sure settings in the /etc/nsswitch.conf
file are configured for the way you want authentication information
to be found.
If a user is created on a local server (in files) and the user then
attempts to rlogin
to that server, the home directory
will not be found, and the user is placed in the root
directory.
The following error message appears:
No directory! Logging in with home=/
If you receive this error message, first, determine that a valid home
directory does exist. Depending on where the home directory was
supposed to be created, look in the /etc/auto_home
file
or auto.home
(NIS) or auto_home.org_dir
(NIS+) map for possible errors.
When you are satisfied that a valid home directory does exist, as
root, edit the /etc/auto_master
file and move the +auto_master
entry to the last line in the file. Then run the /usr/sbin/automount
command to make this change take effect.
Problem: You are unable to see any rights when you open the Rights tool. The most likely reason is that tables containing the rights information have not been created and populated.
Solution: Run the smattrpop
command,
which populates security attribute databases in a name service.
(For detailed information about smattrpop
see the man page.)
The smattrpop
command updates role-based access control
databases in target NIS, NIS+, or local /etc
files from
the corresponding databases in a source name service or files.
Note: smattrpop
is not a remote command, so both
the source and target domains must exist on the same server.
Typically, this means you will be updating a name service domain's
tables from the local /etc
files on the name service
master server.
While there are many options supported, you can run the command from
the source (-s
) to the target (-t
) with all
,
to include all the databases: auth_attr
(authorizations), prof_attr
(rights), exec_attr
(commands), and user_attr
(extended user attributes).
For example, the command
/usr/sadm/bin/smattrpop -s file:/myserver -t
nis:/myserver/east.sun.com all
copies all four databases from the local system's /etc
directory (where the User Manager tools were installed) into the
corresponding table in the NIS domain east.sun.com
,
where myserver
is the master server for this NIS domain.
This command will not populate the target user_attr
with
the root
entry. Nor will it populate that user_attr
table with roles (unless you use the -r
option, for roles).
If you want the alert to begin appearing again, first stop the Solaris Management Console (click Console->Exit in the console). Then restart the console (/usr/sadm/bin/smc
).