LDAP-UX and Trusted Systems

[support_5]

Hi all,

I was wondering if anyone knew if using LDAP-UX (and an LDAP repository with unix account information in it) will work with HP-UX Trusted Systems?

Or is it necessary to use the traditional unix method of storing everything in the /etc/passwd file?

Or could I compromise and use shadow passwords?

If shadow passwords are an option, is there any good documentation on it that you could refer me to?

Comments welcome.

Thanks heaps

- Andrew

[James R. Ferguson]

Hi Andrew:

See here for a bit more information on the HP-UX implementation of Shadow Passwords:

http://h20293.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ShadowPassword

Regards!

...JRF...

[Antonio Cardoso_1]

Hi Andrew,

tsconvert will move (shadow) the passwords from /etc/passwd to /tcb directory.

check http://docs.hp.com/en/B2355-90950/index.html
at §8 "Trusted System Security" and following, "Managing Trusted Passwords and System Access", "HP-UX Shadow Passwords"

Change to trusted system:
/usr/lbin/tsconvert -c

Revert to non-trusted system:
/usr/lbin/tsconvert -r

[Ermin Borovac]

You can find LDAP-UX documentation here.

http://docs.hp.com/en/internet.html#LDAP-UX%20Integration

In particular you can read about integration of LDAP-UX with trusted mode

http://docs.hp.com/en/J4269-90051/ch04s02.html

[Sameer_Nirmal · Accepted solution]

Yes it is very well possible to use LDAP-UX , Netscape LDAP server and HPUX Trusted systems.

You need to use "/etc/pam.ldap.trusted" file ( which is provided as sample file for LDAP-UX & Trusted Mode support) as /etc/pam.conf file. Saying that make a copy of existing "/etc/pam.conf" and copy "/etc//pam.ldap.trusted" file as "/etc/pam.conf".

Refer this link.
http://docs.hp.com/en/J4269-90040/apc.html

[support_5]

Hi,

Thanks for the replies. One more question:

When I run the /opt/ldapux/migrate/migrate_passwd.pl script, I find that the password field doesn't get imported into LDAP. Isn't this a bit of a problem? Coz wont that break authentication? The only way is to untrust the system, run the migration script, then re-trust the system, but then I think authentication breaks again.

So how can I get the passwords from a trusted system into LDAP? How can I keep authentication working?

Or should I go shadow passwords and the "Standard Mode Security Extensions" product? What do you think?

Thanks.

- Andrew

[Steven E. Protter]

Shalom Andrew,

There is no password information in the /etc/passwd file on trusted systems.

Therefore it is not migrated by the script.

The question is, will LDAP-UX function like that. There should be a workaround for this.

SEP

[support_5]

Here is a very bodgy work around. I noticed in the migrate script that it checks shadow files for the passwords. So I wrote a command to generate a dummy shadow file from the tcb database:

users="`cat /etc/passwd | cut -f 1 -d :`"
for user in $users ; do
first_letter="`echo $user | cut -c 1`"
upasswd="`cat /tcb/files/auth/${first_letter}/$user | grep u_pwd | cut -f 2 -d :`"
passwd="`echo $upasswd | sed 's/u_pwd=//g'`"

echo "${user}:${passwd}::::" >> /etc/shadow
done



assuming the /etc/shadow file doesn't exist, it will generate one and I've tested the migrate_passwd.pl script and it does indeed read from the shadow file and put the crypted password field into the output ldif file ready for import. I don't know if the crypted password field format will work with LDAP or not, but it certtainly does read it and put it into the field in the ldif file.

There should be a script to migrate in trusted computer database files into ldap! Come on, HP, how about it?

- Andy

[Sameer_Nirmal]

Andy,

First thing you need to ensure that you keep important system users like root etc. be authenticated by direct OS login and not through LDAP. Make a copy of passwd file , remove those users from it and then use remaining users for LDAP authentication.

What you see in the ldif file created using the migrate script?

Can you mention following
HP-UX version?
LDAP-UX version?
Which LDAP server you are using?

[support_5]

Hi,

Thanks, yes that is what I have done. Basically we have it set up so that if a user id is less than 150 or so, then it stays in /etc/passwd.

A sample entry in ldif format from the migrate script of a trusted system

dn: uid=sysajg,ou=People,dc=workcover,dc=qld,dc=gov,dc=au
uid: sysajg
cn: Andy Gray
objectClass: top
objectClass: account
objectClass: posixAccount
userPassword: {crypt}BCktHtPY/9VM.
loginShell: /usr/bin/ksh
uidNumber: 1152
gidNumber: 100
homeDirectory: /home/sysajg
gecos: Andy Gray,,,

The same entry if I have my bodgy generated /etc/shadow file (see above) and the generated ldif file looks like this:


dn: uid=sysajg,ou=People,dc=workcover,dc=qld,dc=gov,dc=au
uid: sysajg
cn: Andy Gray
objectClass: top
objectClass: account
objectClass: posixAccount
userPassword: {crypt}qNxAxxAxxxTrw
loginShell: /usr/bin/ksh
uidNumber: 1152
gidNumber: 100
homeDirectory: /home/sysajg
gecos: Andy Gray,,,

- Andy

[support_5]

Also, more information:

HP-UX version 11i (11.11)
LDAP-UX version (J4269AA) B.04.00.02
Using RedHat Directory Server 7.1
NSDirSvr7 B.07.10.10 Netscape Directory Server v7 for HP-UX

(It's still called Netscape Directory Server, but it's actually released by RedHat now)

- Andy

[Sameer_Nirmal]

Andy,

It seems you are using "SASL DIGEST-MD5" authentication.

Try using authentication method as "Simple".
Remember to restart the ldapclientd daemon after the change is done.

Referring to your previous posts..

The Standard Mode Security Extension is only meant for HP-UX 11.23 Sept'04 or later.

You can't have trusted system security database imported in LDAP. As mentioned in the documentation, the two entities would "co-exist".

[support_5]

Hi,

thanks for the reply. Actually, I am using the "simple" method. I haven't yet had a chance to try the encryption methods.

Thanks.

- Andy

[support_5]

Hi all,

An update of where I am at:

I have RedHat directory server 7.1 installed on a HP-UX 11.11 server (called server1)(which is not trusted systems). I created a profile on the ldap server and configured ldapux. I have run the migration scripts on that host and imported the resulting ldif files into the directory server using "ldapmodify". I setup /etc/nsswitch.conf and /etc/pam.conf. Then I removed the imported entries from /etc/passwd (NB I didn't import important system users or grooups). What I found was that I was able to log into the system, and all my user files were fine. Even after a reboot, it worked fine.

I then removed the added entries so I had a fresh database again. I then did exactly what I had done above, except it was on an 11.23 server (which wasn't running trusted systems either) and the ldap server was still on 11.11.

What I found was that configuring ldapux was fine, it created the profile fine. I ran the migrations scripts and attempted to import the generated ldif files using ldapmodify, except this time I got the following error message:

[server2]:/etc # /opt/ldapux/bin/ldapmodify -a -c -e /tmp/rejects -f /tmp/server2_passwd.ldif -D uid=admin,ou=.....
ldap_simple_bind: Can't connect to the LDAP server - Connection refused

So I can't run ldapmodify on server2 (11.23) coz it can't connect to the ldap server. Why would that be? NB, I am using the "simple" option in the ldapux setup script.

Anyway, what I could do was copy the ldif files to server1 (11.11) and run the ldapmodify command there and that worked fine. So I now have an LDAP directory full of the user accounts that used to be on server2.

I checked and server2 can indeed read the ldap directory, because when I delete the users out of /etc/passwd, the files ownerships of those users still finds the correct username for that uid. Also, nsquery works when I run: nsquery passwd .telnet

However, I am unable to log in as a user on the system.

eg telnet says:
login: tmpusrac
Login incorrect
login:

And so it won't let me log in anymore.

By the way, I have setup nsswitch.conf correctly, and used the /etc/pam.ldap file and copied that over the top of /etc/pam.conf. I have done this on both server1 and server2. So they both should work, but only server1 does. Why is this? Remembering that server1 is also hosting the ldap server, but theoretically that shouldn't make any difference.

Can anyone tell me what's going on here, or any ideas?

Thanks all.

- Andy Gray

[support_5]

In hind-sight, I might post the above in another thread.

- Andrew