Point an existing cube to a new directory server? 1

[puppyquestion1]

Quick question. We have an existing cube that is secured on a DEVELOPMENT bed's directory server and want to move that cube over to a TEST bed's directory server, without having to rebuild the cube.

Both the development bed and the test bed have a SunOne LDAP server, and both have the exact same user classes, users, etc.

However, when we try to move a cube (not the PYI, the MDC file) from development to testing, we can't open the cube and get an "Access is denied" message.

Is there anyway to repoint the cube to the new directory server without having to rebuild it everytime on the test bed?

I looked on Congos' support site and searched this one, but couldn't find a procedure.

Thanks.

 

[flex13]

JUst because the users and user classes are same isn't enough. If the two lae files aren't from the same source, then the internal ID's are different. Basically, this means that the users are NOT the same to the cube, thus resulting in the error message.

To resolve that, you will need to export the lae file from the environment that built the cubes, and import into the new desired environment.

 

[puppyquestion1]

Thanks flex.

I'm going to repeat what I think you said (my problem, not yours, thanks!). Please confirm if I understood you right.

I have a namespace (let's say, named "bubba") in environment 1 that has a user class (let's say, named "sally"). Environment 1 is running an instance of SunOne LDAP to host "bubba".

I have a second namespace (same name, "bubba) in environment 2 that has a user class (same name, "sally"). Environment 2 is running a second instance of SunOne LDAP to host it's "bubba" namespace.

I think you're saying that Environment 1 LDAP.bubba.sally does not equal Environment 2 LDAP.bubby.sally, unless I export to LAE from environment 1 and import the LAE into environment 2? That is, I cannot move a cube built in Environment 1 to Environment 2 even if the runtime configuration of the server in Environ 2 running the copied cube points to a namespace with the same name which also has user classes with the same name?

If true, that really sucks. I would have hoped they (Cognos/SunONe/whoever) would have abstracted the authentication before you hit the actual namespace without putting some unique ID in the namespace.

Anyway, thanks again flex. Again, I would appreciate you confirming.

 

[Lysen]

You understand it correctly, Puppyquestion.
I've had the same problem a week ago while going from a Windows 2000 to a new faster server running Windows 2003...

I had the directory server set up the same way on the new as on the old, but then I got all these unauthorized cube errors. *sigh*

And I totally agree with you.. it just plainly sucks!
:-(

thankfully there's still the export import of the LAE, but it's still a weird way to go...

 

[flex13]

You are right, but this is an LDAP standard based on which attribute that you authenticate against. SunOne has nsuniqueId, Active Dirtory has ObjectGUID, etc. Best practice dictates that this is how you should set up authentication. Otherwise you open yourself up to a SERIOUS security hole.

For instance, you have a John Smith user who has access to teh EAST region of you cube. Say he leaves teh company and anotehr John Smith gets hired. When he gets added to the namespace, he'd inherit the previous users rights if you just authenticated against the name alone.

You say it sucks, and from a convenience stand point, yes. But from a security stand point, I'd say this is ingenious.

Anyway, it's my two cents ...and the way that it is.

 

[puppyquestion1]

Thanks all. I appreciate the help. We've basically exported the .LAE from one site and imported it into the other. The security part that flex13 mentioned does make sense.

But from a convenience aspect, it still does suck. Heh.

Later.