I'm currently trying to mix local and LDAP users on an AIX 7.1.
I've triied many things.
My LDAP Server in on a CentOS - OpenLDAP (which works fine with linux).
I'm currently stuck on AIX at how to declare LDAP AND Local users.
Here's what i did :
/usr/sbin/mksecldap -c -h 'ldap03' -a 'cn=admin,o=other,c=fr' -p 'secret' -S 'RFC2307'
chsec -f /etc/security/user -s default -a SYSTEM='compat or LDAP'
I also triied
chsec -f /etc/security/user -s default -a SYSTEM='compat or LDAP'
chsec -f /etc/security/user -s default -a registry='LDAP'
But like this, i can't connect on my local users but i can connect to LDAP user with ssh and while connected to my AIX.
With the current configuration, i'm able to login to local and LDAP users BUT while trying throught ssh, i get "Permission denied, please try again." error
afaiu users are there, both local and LDAP, you can login using both types of users using standard AIX tools/procedures, such as "normal" login, telnet, ftp, but you receive some error trying to open ssh session. Am I right?
Do you have problems opening an SSH session with an LDAP user or with a local AIX user or with both types of users?
Connection
su to local user Works
su to LDAP user Works but can't use chuser/rmuser and all user commands (like sudo -l with a LDAP user)
ssh to local user Works
ssh to LDAP user Permission denied, please try again. (Like when you type a wrong passwd)
What i would like to do :
Connection
su to local user Works
su to LDAP user Works
ssh to local user Works
ssh to LDAP user Works
mkuser Creates local user
rmuser Delete local user
chuser Changes local user
lsuser List local and LDAP user
mkuser/rmuser/chuser -R LDAP works but my LDAP server will block this
In fact i would like AIX users works like Linux users (at least it works like this on my Linux servers)
you have to specify for all local (already existing) users SYSTEM = "files" and registry = files - or e.g. the login process will search them on the LDAP-Server.
If LDAP is the default you need to specify that a user should create or exists locally:
mkuser [-R files] SYSTEM='files' registry='files' testuser
rmuser -R files testuser
passwd -R files testuser
lsuser -R files -a SYSTEM registry ALL
...
c) check your current defaults for SYSTEM and registry
michael@x071:[/home/michael]rity/user | egrep "SYSTEM|registry" <
* Possible values: SYSTEM,NONE,token;username.
* SYSTEM : Describes normal password authentication in
* an authentication grammar. See SYSTEM
* auth1 = SYSTEM,mylogin;mary
* SYSTEM Describes Version 4 authentication requirements. This
* SYSTEM grammar manual pages.
* SYSTEM = "DCE OR DCE[UNAVAIL] AND compat"
* registry Describes where this user is administered. It is used
auth1 = SYSTEM
SYSTEM = "compat"
d) notice in the comments the example for SYSTEM way back when (1995ish) when DCE was more popular. I will rephrase this:
if (DCE authentication succeeds)
then authentication successful;
if (DCE not available AND compat authentication succeeds)
then authentication successful;
In other words, "compat" is only used when DCE is unavailable. Yours should substitute DCE with LDAP.
e) From memory (i.e., without additional testing) I cannot say exactly what registry = LDAP is doing. But I expect, not what you expect. Maybe if you have added the AIX schema into your CentOS LDAP server it might work. But since mkuser/chuser/etc -R LDAP is not working I expect the LDAP server is refusing because it does not have the AIX (LDIF) schema for all the attributes in /etc/security/user (to name just one of the registry 'files').
I suggest returning "registry = files" as the default setting.
chsec -f /etc/security/user -s default -a registry=files'
f) For users, rather account names, that must be local add at least "SYSTEM=compat" to the user, e.g., for michael
michael@x071:[/home/michael]chuser SYSTEM=compat michael
michael@x071:[/home/michael]grep -p michael: /etc/security/user | egrep "SYSTEM>
SYSTEM = "compat"
Other stuff) - back from 2000 when I designed the AIX security curriculum.
The key two attributes for Identification (aka username) and Authentication (aka password verification) are auth1 and SYSTEM . This is easy to delegate to an external I&A service, e.g., LDAP, DCE or kerberos server.
The third /etc/security/user attribute is registry - and, with no access to program code, design documents, etc. to verify it I have always understood this to be where to look for additional information about a user that is not uid/gid to username/groupname lookup (and v.v.). In a literal sense I take this to mean - when registry=LDAP (as is your case) to not even look in /etc/passwd for my HOME directory or default shell (for the RFC2307 attributes that any UNIX oriented LDAP server should have).
You might be able to test this by changing the home directory of a user using both -R files and -R LDAP . If you do, please post results and expand my understanding!
Thanks for your reply,
I've already triied this, it's not a suitable solution as we may create local and LDAP users anytime. What could be perfect is something like :
/etc/security/user
default:
admin = false
login = true
...
SYSTEM = "compat or LDAP" <-- this work
registry = files or LDAP <-- Will not work of course, registry can only accept 1 parameter
I really want to stay with the default behavior:
all user operations will be local and if they can't be performed locally, they will try the LDAP.
Example
if i loggin to test user, my AIX should search locally, if it doesn't find anything, it'll try on LDAP
---------- Post updated at 07:13 AM ---------- Previous update was at 07:01 AM ----------
Thanks for your reply,
a) b) I'm root
# id
uid=0(root) gid=0(system) groups=2(bin),3(sys),7(security),8(cron),10(audit),11(lp),229(idsldap),15(dbsysadm)
# lsuser -a registry SYSTEM root
root registry=files SYSTEM=compat
c) My defaults
# lssec -f /etc/security/user -s default -a registry
default registry=LDAP
# lssec -f /etc/security/user -s default -a SYSTEM
default SYSTEM="compat or LDAP"
e) registry = LDAP
This does not really do what i want as when you mkuser a new user, his registry will be on LDAP by default, and i want it to be files by default.
f) For users, rather account names, that must be local add at least "SYSTEM=compat" to the user, e.g., for michael
It's not something that i would like to as as we have a large number of accounts and they are not all the same depending on the server. It would be a big work to declare the registry and SYSTEM parameters of our local users.
Other stuff) I understood that registry is where to look for user informations and security files.
If you declare registry to LDAP, AIX will look for the user's files (passwd, group, shadow) on the LDAP, even if the user has SYSTEM = compat.
Here's an example:
Conditions : SYSTEM = compat, registry = LDAP
mkuser test
passwd test
Changing password for "test"
User "test" does not exist.
Error changing password for "test".
grep test /etc/passwd
test:*:210:1::/home/test:/usr/bin/ksh
---------- Post updated at 07:34 AM ---------- Previous update was at 07:13 AM ----------
I'm trying to exactly do what i said earlier
Connection
su to local user Works
su to LDAP user Works
ssh to local user Works
ssh to LDAP user Works
mkuser Creates local user
rmuser Delete local user
chuser Changes local user
lsuser List local and LDAP user (or just the local users)
mkuser/rmuser/chuser -R LDAP works but my LDAP server will block this <-- this is the wanted behavior
If i put registry to LDAP, all user will be searched on the LDAP.
I think i need the SYSTEM = 'compat or LDAP' to login to local and LDAP users.
Normally, for user authentication admins want only one or the other, not both being checked.
I have never tried SYSTEM = compat OR compat[UNAVAIL] AND LDAP as I expect compat to always be available. Assuming compat[UNAVAIL] does not work then I think SYSTEM = compat OR LDAP comes closest to your authentication needs.
For accounts that must be local, like root - the solution has been to add specific
SYSTEM=compat
entries.
If your goal is to be as close to default as possible, set registry=files
The thing is that on CentOS, redhat servers we have, we can login to local users and LDAP users, and when performing actions on users, it only affects local users.
If it's not possible to do it on AIX well... I'll have to find a workaround.
Maybe I do not understand the question. But, let's say michael exists in both LDAP and AIX domains.
To change the account michael 'locally' I would use:
# chuser -R files .... michael
And the same, or a different change on LDAP would be:
# chuser -R LDAP .... michael
However, I expect most changes using chuser -R LDAP ... michael will fail if your server only supports the RFC2307 DIT or LDIF specification (basically, what is found in /etc/passwd and /etc/group and the shadowed encryption of the password).
Basics:
when you ran the mksecldap command you configured the file /etc/security/ldap.cfg and arranged for the daemons to start.
Look at this section on your server - I do not have LDAP configured so all are commented out - you should have a few uncommented.
Line numbers are approximate!
unix_auth is default, and preferred
+30 # Authentication type. Valid values are unix_auth and ldap_auth.
+31 # Default is unix_auth.
+32 # unix_auth - Retrieve user password and authenticate user locally.
+33 # ldap_auth - Bind to LDAP server to authenticate user remotely through LDAP.
+34 #authtype:unix_auth
Preferred is "system" and update /etc/security/login.cfg to use sssh256
+60 # Default is "crypt".
+61 # crypt - Specifies the legacy crypt() (DES) algorithm.
+62 # system - Specifies the syste-wide password algorithm that is
+63 # defined in /etc/security/login.cfg. Using syste-wide
+64 # password algorithm may require that LDAP server's
+65 # password encryption be disabled to avoid double
+66 # encryption, which can make the password unusable.
+67 #pwdalgorithm:crypt
These are the user attributes defining the schema used. Are these uncommented? What do they point too?
And finally, for the basics: what is active/inactive here?
+74 # Base DN where the user and group data are stored in the LDAP server.
+75 # e.g., if user foo's DN is: uid=foo,ou=people,cn=aixdata
+76 # then the user base DN is: ou=people,cn=aixdata
+77 #userbasedn:ou=people,cn=aixdata
+78 #groupbasedn:ou=groups,cn=aixdata
+79 #idbasedn:cn=aixid,ou=system,cn=aixdata
+80 #hostbasedn:ou=hosts,cn=aixdata
+81 #servicebasedn:ou=services,cn=aixdata
+82 #protocolbasedn:ou=protocols,cn=aixdata
+83 #networkbasedn:ou=networks,cn=aixdata
+84 #netgroupbasedn:ou=netgroup,cn=aixdata
+85 #rpcbasedn:ou=rpc,cn=aixdata
+86 #automountbasedn:ou=automount,cn=aixdata
+87 #aliasbasedn:ou=aliases,cn=aixdata
+88 #bootparambasedn:ou=ethers,cn=aixdata
+89 #etherbasedn:ou=ethers,cn=aixdata
+90 #authbasedn:ou=authorizations,cn=aixdata
+91 #rolebasedn:ou=roles,cn=aixdata
+92 #privcmdbasedn:ou=privcmds,cn=aixdata
+93 #privdevbasedn:ou=privdevs,cn=aixdata
+94 #privfilebasedn:ou=privfiles,cn=aixdata
+95 #domainbasedn:ou=domains,cn=aixdata
+96 #domobjbasedn:ou=domobjs,cn=aixdata
---------- Post updated at 02:17 PM ---------- Previous update was at 02:14 PM ----------
I expect it is using, by default, the same schema (attribute mapping) in LDAP and it does in it's local files.
AIX includes an LDAP server at no additional charge for AIX user admin. Maybe using that will get you 90% of the way. You can still configure AIX to go to a 'foreign' LDAP server for "login" verification.
AIX introduced a new alternative authentication control attribute "authcontroldomain" from AIX 6.1 Tl07 and 71 Tl01 releases. When this attribute is set, SYSTEM and registry attributes are stored or retrieved from that database. For local users, SYSTEM and registry attribute are stored in /etc/security/user file irrespective of the authcontroldomain value.
The authcontroldomain attribute needs to be defined with a loadmodule name which is defined in the /etc/methods.cfg or /usr/lib/security/methods.cfg file. This attribute needs to be defined in the /etc/security/login.cfg file under the usw stanza.
authcontroldomain attribute can be set for a system as using the chsec command. For example:
chsec -f /etc/security/login.cfg -s usw -a authcontroldomain=LDAP
/etc/security/user
default:
SYSTEM = "files"
registry = files
Quick Test: LDAP and local User Login works fine without further specifying SYSTEM or registry.
Security load modules are defined in /usr/lib/security/methods.cfg file. User identification is done based on order in, which load modules are defined in methods.cfg file. Local load module information is not defined in the /usr/lib/security/methods.cfg file. However, the user information will be verified first in local module; then the order that is defined in methods.cfg file will follow.
Thanks -=XrAy=-, for reminding me that sometimes developerworks has new information, not just rehashed.
AIX_user_324891 - lots of feedback in both directions. I am still not sure exactly what you want to achieve. If I was at your location I would ask for a demonstration of what you do on your linux servers - and then think about how I would approach that on AIX. Security is Managing Detail - without control of the details security is not - imho. So, describing, in definitive terms helps an old fool like myself (fool because I play blind (I prefer saying I try to not assume) to things everyone else sees as self-evident).
Its almost what i need, your solution looks good but now i think i've got a configuration problem , when i login to my ldap user via root (su ldap_user) it works, but when i try to login with a normal user i got an error message.
---------- Post updated at 09:15 AM ---------- Previous update was at 08:50 AM ----------
Here's a demonstation of what i can do on my linux servers :
First i've got a linux user in my LDAP server like this : uid=ldap_user,ou=linux_users,ou=other,o=other
When connecting to our CentOS server, i just do this :
ssh ldap_user@vhzva03
[ldap_user] $ id
uid=9999(ldap_user) gid=16000(network_admin) groupes=16000(network_admin)
Now on that vhzva03 if i grep /etc/passwd, i don't find the ldap_user (as expected)
[root] # grep ldap_user /etc/passwd
When looking with a ldapsearch command ldapsearch -b "o=other" -x "(cn=ldap_user)"
seems to be a workaround. Now i can SU from an LDAP user to another LDAP user. If i try to delete a ldap user (as root), i get an error: 3004-698 Error committing changes to "ldap_user".
BUT: I noticed that the chsec command throw the same error.
# chsec -f /etc/security/user -s default -a SYSTEM="compat or LDAP"
3004-698 Error committing changes to "default".
So the use of authcontroldomain seems to be buggy. You/I will need do further tests.
I've got another problem...
Here's whats happening when i try to change the user password as root:
vhqut11:root
# passwd ldap_user
Changing password for "ldap_user"
ldap_user's Old password:
ldap_user's New password:
Re-enter ldap_user's new password:
It works but on my LDAP, the password encryption is : clear. (it was md5crypt before passwd)
Now when i change the passwd with the ldap_user, it doesn't even work :
vhqut11:ldap_user
# passwd
Changing password for "ldap_user"
ldap_user's Old password:
ldap_user's New password:
Re-enter ldap_user's new password:
A password change is not allowed at this time.
, when i login to my ldap user via root (su ldap_user) it works, but when i try to login with a normal user i got an error message.