Hi
I would like to copy some user policy ( such as login time out , password expired time, number of failed login before user is locked, ... ) from one server to another server. I had copied necessary files ( in /etc and /etc/security ) to new server, but something didn't work.
I guess that I have to reboot server, but I don't want to do that. May I reboot some services in this case, so that all the policy would work ??. If yes, which services ???
Thank for read.
Q: Are the user present on both servers? With same passwd? ( and so hoem directories exist etc...)
I realy hope you have a made backup of these files.
Which files have you copied so far?
I would suggest to copy the /etc/security/login.cfg and
(only) the "default:" Stanza from /etc/security/user.
There is no need to reboot the server.
Regards
If you want to clone a bunch of users, it might be better to use the output from lsuser as root (you get more information) to build a deck of mkuser commands, ensuring that the groups names match in advance.
You would need to keep the UID & GID numbers the same, especially if there is NFS involved or you move data with tar or other methods that put back permissions.
As for copying the password details, this is fraught with danger. You would be best to ensure you get a quiet time and do a big edit to replace the specific passwords and other attributes in /etc/security/passwdone at a time having taken a backup copy first. There is a serious risk that you could leave yourself unable to login to your target server.
You will also need to consider if/how you use ssh keys, remote login and any ftp restrictions that might be in place. There may of course be other software installed or applications that have their own account management too.
Are you wanting to duplicate the whole server by any chance? If so, then mksysb is a better way, although you have to be careful you boot without the network plugged in first time else you will get IP conflicts with the current live server.
Robin
Files I copied to new server ( same OS version )
/etc/group
/etc/passwd
/etc/security/group
/etc/security/limits
/etc/security/passwd
/etc/security/.ids
/etc/security/environ
/etc/security/.profile
/etc/security/login.cfg /
/etc/security/user
OK but what about the users? Their home directories??? the one you see in /etc/passwd... Then you might have mismatches between the content found in the user's .ssh directory ( yes the public keys ... the local keys wont match with the server where you copied...) etc...
Unix does not deal with "policies", there are just (access) rights: read, write and execute. What you are after is spread out over several different portions of the OS software:
login time out if you mean a time of inactivity after which a user is logged out: this is a shell variable, called "TMOUT", which is usually set in /etc/enviroment as a read-only variable. Many security auditors insist on it, but it is idiotic (meaning: it doesn't serve the proposed purpose in any way), it can easily be circumvented and it might even be harmful without any practical gain. My suggestion is not to implement it at all.
password expired time is a property of the user account and you should use the chuser ( mkuser for new users) command to set or change it.
number of failed login before user is locked same as above.
No, not at all. Booting loads a new kernel image into memory. Have you changed anything on the kernel? No! Therefore....
The users are created by copying /etc/passwd , but about the home-directories and their contents, ssh-keys and similar information you are absolutely right.
As rbatte1 has already said: ONLY USE THE OS COMMANDS to do things, do not dabble around in configuration files - at least not to achieve ordinary things like creating/changing users and definitely not as long as you are not 1000% sure what you do.
Rule of thumb: if you have to ask how you should not do it at all.
PS: the perhaps cleanest way to implement uniform user accounts across a scenery of systems is to use some system designed for that: Kerberos, LDAP, NIS, NISplus, DCE, X.500, ....
I hope this helps.
bakunin
As far as "policy" goes, that would only be the so-called default: stanzas in several files in /etc/security.
There are other "policy" related files, also in /etc/security - most of these end in .cfg (e.g., login.cfg).
If you are trying to duplicate users on both servers my preference would be to use LDAP and/or Kerberos (on AIX). Also because I expect you will need to keep the user administration synchronized in both systems.
As to HOWTO copy the configuration/policy files I recommend you read up on AIX Runtime Expert at: https://www-01.ibm.com/support/knowledgecenter/ssw\_aix\_61/com.ibm.aix.osdevice/artex_main.htm
You should have something like this (for AIX 6.1 at least) installed by default.
michael@x071:[/home/michael]lslpp -L | grep artex
artex.base.rte 6.1.9.45 C F AIX Runtime Expert
artex.base.samples 6.1.9.30 C F AIX Runtime Expert sample
Hope this helps.
Thanks guys for your help
It seems that copying all these files doesn't make everything works. Something works, but something doesn't, such as the login time out as bakunin said, I have to set the TMOUT variable in /etc/profile ( AIX 5.3 ) manually, or the ssh authentication - also has to be reconfiged again ...
I can only fix which I see. I'm not the person who config the old servers, so I don't know exactly whether everything is OK ot not. Maybe next time I'll use "clone rootvg", it would cost a lot of time ( because of the number of servers ), but it could ensure that everything's OK.
Exactly this is the main problem: you never can be sure if you have found the last problem.
This - take an mksysb and restore it - will make sure absolutely everything: users, print queues, groups, cron entries and whatever you can think of is copied. If you have several of these servers you should take an mksysb for system backups regularly anyway. You can boot a new hardware from this image and (re-)install the competely configured system from that, which will perhaps less time than to install an unconfigured system and then put some (probably incomplete) configuration onto that.
I hope this helps.
bakunin
Personally, I have not worked enough with AIX Runtime Expert to give a quick example - but this is one of the things it was intended for - even if it is only to see what the differences are.
Further, as you talk about "old" and "new", in particular not knowing what the old policies were, or why. I would be nervous about copying old, unknown policies because I have no way of knowing whether they are sufficient to meet the demands of today's (security) requirements. Also, as you are probably moving to new hardware - are the performance settings correct for the new environment.
While I can understand that you want to transfer users - and it if concerns many users - taking some time to learn about the tools available on AIX at no additional charge (a few that come to mind are: aixpert (i.e. AIX Security Expert) for hardening, aix runtime expert for applying system profiles, RBAC, Trusted Execution, etc..
imho - you are doing yourself and/or your business/employer a disservice by not looking in to what AIX offers.
I wish you many happy days as a (new) AIX admin!
Maybe I can help 
The directory /etc/security/artex/samples holds a set of xml files with possible system settings which can be managed by artex.
.svn chssysProfile.xml envProfile.xml mkuser.defaultProfile.xml secattrProfile.xml
acctctlProfile.xml chsubserverProfile.xml errdemonProfile.xml namerslvProfile.xml shconfProfile.xml
aixpertProfile.xml chuserDBKLDAPProfile.xml ewlmProfile.xml nfsProfile.xml smtctlProfile.xml
all.xml chuserDBKfilesProfile.xml ffdcProfile.xml nfsoProfile.xml syscorepathProfile.xml
alogProfile.xml chuserProfile.xml filterProfile.xml nisProfile.xml sysdumpdevProfile.xml
authProfile.xml classProfile.xml gencopyProfile.xml noProfile.xml trcctlProfile.xml
authentProfile.xml coreDBKfilesProfile.xml iooProfile.xml probevueProfile.xml trustchkProfile.xml
chconsProfile.xml coreProfile.xml krecoveryProfile.xml rasoProfile.xml tsdProfile.xml
chdevProfile.xml default.xml login.cfgProfile.xml roleProfile.xml viosdevattrProfile.xml
chlicenseProfile.xml devProfile.xml lvmoProfile.xml ruserProfile.xml vmoProfile.xml
chservicesProfile.xml dumpctrlProfile.xml mktcpipProfile.xml schedoProfile.xml
The following command/example save the settings of the login.cfg on the current server.
artexget -q -r -f xml /etc/security/artex/samples/login.cfgProfile.xml >/tmp/current.login.cfgProfile.xml
To restore these settings (copy the newly created file to another server and) run the following command:
artexset -l all /tmp/current.login.cfgProfile.xml
There is also a all.xml profile which contains all artex managed settings. This profile can be used to copy over the whole system settings inclusive of all known users and groups.
Regards
This AIX runtime expert seems to be well worth a close inspection. Good job, -=XrAy=-!
bakunin
Thank you very much bakunin,
we use Artex to compare the current system settings against initial saved settings.
This helps if something no longer work as expected and alleged no one has touched your system. 
artexdiff -r -q -c -f txt /tmp/nfsoProfile.xml
/tmp/nfsoProfile.xml | System Values
nfsoParam:nfs_use_reserved_ports 0 | 1
In this case '0' is the old and '1' the new value for nfs_use_reserved_ports.
Regards