Question : Virtual Office Teams Failing - NMAS error

I am attempting to change the location of the Virtual Office file store. There seems to be some sort of name resolution issue. I can successfully create a new team. However, when I try to go into that team in Virtual Office I receive a 500 error in my browser.  

Here's the clue... When I turn on DSTRACE with the NMAS option, this is what is returned right after clicking on the team in VO:

5: Create NMAS Session
5: NCPCheckIfLocalUser: client supplied user DN CINCY\.Port Byron.O=top
5: ERROR: -601 NCPCheckIfLocalUser: DDCResolveName
5: ERROR: -601 NCPCheckIfLocalUser failed
5: NCPCheckIfLocalUser failed -601
5: Client Session Destroy Request
5: Destroy NMAS Session
5: Aborted Session Destroyed (with MAF)

Immediately after this the 500 error (with lots of script similar to what you get when Tomcat can't authenticate to something) in the browser.

The key line here is: "5: NCPCheckIfLocalUser: client supplied user DN CINCY\.Port Byron.O=top" ...  This is the user supplied in the VO environment team file share setting.

BUT... The O= (organization) is NOT "Top".  The user is cn=cincy.o=port byron.  I can not find anywhere that shows the O=top - there is no such organization container.  In addition, I'm not sure where the backslash after the CN=Cincy is coming from.

No matter how I specify the user name in the VO environment I get a similar NMAS error -  (cincy, or cincy.port byron, or cn=cincy.o=port byron, or cn=cincy,o=port byron, etc.).

Any thoughts?

Answer : Virtual Office Teams Failing - NMAS error

First off, does the NMAS server have read-write replicas of the partition holding the security container, and of the partition(s) the user objects are in?  Does the NMAS server object have the appropriate eDirectory object/attribute rights?

If not, then NMAS may not be able to tree-walk to find the user object, which is what the -601 errors are indicating.  This exact error happens with BorderManager 3.8 and NMAS 2.3.  It's "supposed" to be fixed in NMAS 2.3.4 or greater but

Since you're on NMAS 2.4 I'd suspect this isn't your issue, but it's worth exploring.

Secondly, what NMAS method is being used for authentication to VO?  Is it Universal Password?  If so, Universal Password uses >secure< LDAP for user lookup and authentication, so you have to make sure your LDAP server object is using a valid server cert.  But, since you're not seeing LDAP errors or certificate errors, this is probably not the issue.  Do make sure LDAP is set to use port 636 (or whatever port you've selected for TLS/SSL on your LDAP server object) and set System.DirectorySSL=true in your PORTALSERVLET.PROPERTIES file to make sure secure LDAP does get used for those portions of VO that require it.  It's probably already set that way, but...

Thirdly, NetWare 6.5 SP5 should be using a newer version of NMAS than 2.4.  NMAS 2.4 documentation is now in the "archive" section and the current NMAS is something like 3.1.  

Thirdly and-a-half, you don't mention your version/revision level of eDirectory, but IMHO at this point you should be on at the very least version 8.7.3.8 but should probably be on eDirectory 8.8

So anyway, bottom line, check to make sure the NMAS server that VO is using has a read-write replica of the partition that holds the security container (may be [Root] but NMAS setup docs recommend having a separate partition for the security container) AND of whatever container(s) the user objects are in.  Also check to make sure the NMAS server object has appropriate rights to the objects/attributes in those containers.  Also check your LDAP search policy to make sure it can search past its own container level.  If you're using an older version of NLDAP like you're using an older NMAS, you may not have that capability and might have to turn on "dereference aliases" and place aliases for all users in the LDAP objects' container.