Enabling security disables access to server

When I enable security on the sunray server via the administrators console my dtu's will no longer connect. They sit at 26D. When I disable security they will connect again. Any ideas?
[192 byte] By [tfeldmanna] at [2007-11-26 16:42:59]
# 1
This has been reported to happen on Solaris Nevada running on x64 (64-bit x86) machines. What operating system and hardware do you have?
ottomeistera at 2007-7-8 23:10:04 > top of Java-index,Desktop,Sun Ray Software - General Discussion...
# 2
Solaris Nevada build 55 on a v210
tfeldmanna at 2007-7-8 23:10:04 > top of Java-index,Desktop,Sun Ray Software - General Discussion...
# 3

That's interesting, nobody has reported this happening on SPARC until now. What does a 'tail -200 /var/dt/Xerrors' show after you turn on encryption and the Sun Rays get stuck?

There's no known workaround other than not turning on encryption. If you want encryption then you need to run SRSS on one of the supported OS releases. Solaris 10 would be the obvious choice.

ottomeistera at 2007-7-8 23:10:04 > top of Java-index,Desktop,Sun Ray Software - General Discussion...
# 4

I don't currently have access to the server, but could it have anything to do with this error that came up during the utconfig:

rm of /var/opt/SUNWbb/root/home/. is not allowed

rm of /var/opt/SUNWbb/root/home/.. is not allowed

bbcpfiles: Warning: security/pam_unix.so.1 not found

ld.so.1: nscd: fatal: libavl.so.1: open failed: No such file or directory

Killed

It came up with this about mid way through but just kept going on afterwards and said it configured successfully. The security/pam_unix stuff sure makes me think it has something to do with it but I don't really know anything. I did do some checking and there is a libavl.so.1 file in the /usr/lib directory but I can't find a pam_unix.so.1 file anywhere.

tfeldmanna at 2007-7-8 23:10:04 > top of Java-index,Desktop,Sun Ray Software - General Discussion...
# 5
Those reports are unrelated to the crypto problem. The crypto issue is caused by a collision between function names in an SRSS library and a new system library that was introduced in Nevada. I expect we'll release the fix for this problem in a patch for SRSS.
ottomeistera at 2007-7-8 23:10:04 > top of Java-index,Desktop,Sun Ray Software - General Discussion...