jknarr
Contributor
Contributor

Novell OES SP2 and eDirectory TLS

Gentlemen,

I'm trying to join a server to an existing tree. The new server is a VMWare ESX hosted Novell OES SP2 box (SLES 9) and is running SS205 with eDirectory 8.7.3.9.

The box will never configure correctly through the wizard (even specifying scope by hand) and a restart shows:

NewHost:~ # /etc/init.d/ndsd restart

Executing customized settings before stopping the Novell eDirectory server...

Stopping Novell eDirectory server...

.............................. done

Executing customized settings after stopping the Novell eDirectory Server...

Executing customized settings before starting the Novell eDirectory server...

Starting Novell eDirectory server...

+ done+

Executing customized settings after starting the Novell eDirectory server...

Novell eDirectory LDAP Server TCP port is listening.

Novell eDirectory LDAP Server TLS port is not listening.

NewHost:~ #

Any ideas why TLS doesn't work? The usual suspects of time sync and SLP configuration check out correctly.

Tags (4)
0 Kudos
6 Replies
jedijeff
Enthusiast
Enthusiast

I would post this to the novell forums. Have you checked your PKI and NICI infrastructure?

0 Kudos
jknarr
Contributor
Contributor

It's not going to solve it. I eventually tracked it down to a problem with the behavior of nldap when its trying to resolve itself inside of the virtual switching infrastructure. What I did is built a VM using the free VMWare server, then converted it and imported it. I verified the eDirectory instance works inside of the free VM host, then doesn't work inside of ESX. nldap looks like it's trying to resolve itself but because the virtual switch does something funky when you try to talk across your assigned IP address to yourself (instead of using loopback). nldap reports this as a failure.

However, when you bring up ndsd by hand, then query it with consoleone, you can see that eDirectory is correctly configured and servicing requests (TLS or otherwise). I put in a request with our service rep to figure out WTF is wrong with nldap and they haven't gotten back to me as of yet.

0 Kudos
jedijeff
Enthusiast
Enthusiast

I have several edir boxes in vm's running nldap just fine. Odd.

0 Kudos
SafeTinspector
Contributor
Contributor

I have not experienced similar.

I'd guess you already tried mucking about with the HOSTS file to perhaps make it resolve itself back to loopback address instead of real address?

0 Kudos
jknarr
Contributor
Contributor

Wow, just wow. Don't do this. Ever.

The certificates for SSL are generated against the hostname and IP address. You will break anything that uses SSL (like eDirectory TLS, iManager, iFolder...) if you do this.

0 Kudos
SafeTinspector
Contributor
Contributor

Correct me if I am wrong, but the certificates in eDirectory are based off of EITHER the name or the IP address, but not both at the same time. And you can have a separate cert for each name and/or address a server has.

Not to mention a server can have multiple IP addresses bound to it... presumably including loopback.

So if I place an entry in the local HOSTS file that says

127.0.0.1 loopback servername servername.domain.com

then I should not be breaking anything, but I will be assuring that the server is more likely to talk to its loopback address when referencing itself than using one of its bound LAN addresses.

If I have any worries about the certificate, I can recreate it using PKIDiag. The only one possibly affected would be the SSLCertificateIP, which would already be created by now, so it shouldn't be affected at all by the hosts file. If not, or if you wanted to, you could still recreate that cert using PKIDiag, simply select the LAN address instead of loopback when creating the cert and all is fine.

I've never had troubles caused by manual host entries as long as I am careful in the construction and use them sparingly. In fact, some products have difficulties if the hosts file isn't populated enough.

Honestly, I don't see how this would cause a problem. It isn't an elegant solution, but it might be a work-around that'll get you by while you work towards a final solution.

0 Kudos