Integrated Login second (or more) opinon(s)

[highlnder8]

My IT department has been working on this for nearly a year and I'd like a second opinon about what may be happening.

We are experiencing the following error message:
Log In Failed: SystemServerConnectionInvalid

We are on version 9.4 64-bit (we were among the very first to upgrade to the new system).
We have performed the setup routine to enable integrated login (or so it is said).
I have a test machine and have clicked on "Use Integrated Login" on the TM1 Options box under Login Parameters.
I have added an address to my client name's UniqueID under }ClientProperties in the form of: username@domain (John123@abc).
I am logged into the machine as myself.

What are we missing? Apparently Cognos is stumped. My IT department does not have the resources to pursue this 24/7 looking for the answer.

Anything anyone can do to help out with this would be greatly appreciated.

Thanks!!

[Martin Erlmoser]

i hope the tm1 server runs under a domain account?

[paulsimon]

Hi

For it to work easily, the user id that the TM1 Server Service runs under needs to be in the same domain as the users who are accessing the TM1 Server.

At our company all application servers are in a different domain to the users. I forget the details but essentially for it to work in this scenario there needs to be a bi-directional trust relationship between the two domains, which the IT Dept will not allow, and therefore integrated login cannot work at our site. The other avenue that we are pursing is creating a group on the application server and putting user domain users in to this. However, that is taking a while to negotiate, and still may not work.

Regards


Paul Simon

[kangkc]

No, TM1 service does not need to be started under a domain account. Please check whether the server is joined to the domain? If so you can start up TM1 service under local system account and Integrated Login will still work.
I have done this many times and it should work.

Can you post your tm1s.cfg ? You can mask off the sensitive part.

[Alan Kirk]

No, TM1 service does not need to be started under a domain account. Please check whether the server is joined to the domain? If so you can start up TM1 service under local system account and Integrated Login will still work.
I have done this many times and it should work.

It may work for integrated login (never having tried it I couldn't say, and I'll take your word for it) but IMHO it's still not a good idea to run a server under a Local System account even if some things will work when you do so. I learned that one from bitter (or at least tangy) experience.

I accidentally did it once when we were converting from using applications to using services; I forgot to add the extra parameters when I ran the command line to install the service. Everything was hunky dory... until it needed to access a file share on the network and found that it didn't have permission. I changed it over to log in under the correct domain account and all was fine again.

It's interesting that in the "Cognos Proven Practices" document "TM1 Registration and Maintenance of Windows Services" (which I'd provide a link to, but the gods only know where it is on the IBM site) page 6 states that if you have a server running as a local system account you should change it to a domain account to ensure that it has all necessary network access. (Though it doesn't mention integrated login as an issue.)

[kangkc]

Definitely, running under domain account will always be the preferred setup. Anyway, it's off topic for this thread. See if the originator of this thread can provide the cfg configuration. Need to see if it's using NTLM or Kerberos.

[Alan Kirk]

Definitely, running under domain account will always be the preferred setup. Anyway, it's off topic for this thread.

Martin Erlmoser didn't seem to think so, and frankly neither do I given that it may potentially be an issue.

See if the originator of this thread can provide the cfg configuration. Need to see if it's using NTLM or Kerberos.

Wouldn't hurt.

[LoadzaGrunt]

Questions:

• What steps were taken to 'enable integrated login' - you seem to doubt that the correct procedure has been undertaken?
  What is your integrated login setting in the tm1s.cfg for your server instance ?
  Are you using Kerberos or NTLM ?
  Are you sure that your server instance is looking at that tm1s.cfg !?
  How sure are you that you have specified the correct username and domain in the UniqueId field ?
  When you are logged into the test box are you logged into the correct domain ?
  Have you tried to test integrated login functionality directly on the server running the TM1 instance ?

[highlnder8]

Thank you everyone for your replys so far!

Unfortunately, the department that sets up the server configurations is separate from my department that administers the rest of the application, so, while I trust that they set up the configuration according to Cognos's directions, I'm not entirely confident that Cognos's prescription is entirely applicable to our environment.

To answer some of these questions, I'll need to go back to the applicable I.T. team and ask them some of these very questions. When I get a response back, I'll pass it on to the real experts - you.

Thanks all for your amazing responses!!

I'll post back soon.

[highlnder8]

Definitely, running under domain account will always be the preferred setup. Anyway, it's off topic for this thread.

Martin Erlmoser didn't seem to think so, and frankly neither do I given that it may potentially be an issue.

See if the originator of this thread can provide the cfg configuration. Need to see if it's using NTLM or Kerberos.

Wouldn't hurt.

Here are the answers from the cfg file:
SecurityPackageName=Kerberos
and
IntegratedSecurityMode=2

Thank you for your help!

[highlnder8]

Ok, here is the list of questions with my responses.
Thanks for being patient and so helpful!

Questions:

• What steps were taken to 'enable integrated login' - you seem to doubt that the correct procedure has been undertaken?

The steps outlined in the Cognos documentation were followed first to use ETLDAP, and when that failed, Cognos support assisted with setting up without using ETLDAP. However, that has been a failure as well, so far.

• What is your integrated login setting in the tm1s.cfg for your server instance ?

IntegratedSecurityMode=2

• Are you using Kerberos or NTLM ?

SecurityPackageName=Kerberos

• Are you sure that your server instance is looking at that tm1s.cfg !?

Yes, unless there is a way to point an instance to use a tm1s.cfg file that is outside of the directory that contains the instances cubes, dimensions, user folders, etc.

• How sure are you that you have specified the correct username and domain in the UniqueId field ?

At this point, it's my #2 suspect, down from #1 two weeks ago.

• When you are logged into the test box are you logged into the correct domain ?

Yes.

• Have you tried to test integrated login functionality directly on the server running the TM1 instance ?

[/list][/list][/list][/list][/list][/list]

No. I don't have access to the box and my IT liason is not likely to have availability in the near future to assist with testing this.

Also, for those requesting it -
[TM1S]
ServerName=**********
DataBaseDirectory=*************************
LoggingDirectory=***********************
AdminHost=**********
PortNumber=************
Protocol=TCP
NetworkFrame=
Language=ENG
ODBCCatalogName=
ODBCDataSource=
ODBCUserName=
ODBCPassword=
ReadTM1WriteODBC=
SecurityPackageName=Kerberos
IntegratedSecurityMode=2
ReadersBypassWriters=T
ServerLogging=F
IdleConnectionTimeOutSeconds=7200
AllowSeparateNandCRules=T
GroupsCreationLimit=400
UseSSL=T

[David Usherwood]

LoadzaGrunt wrote:

Are you sure that your server instance is looking at that tm1s.cfg !?


Yes, unless there is a way to point an instance to use a tm1s.cfg file that is outside of the directory that contains the instances cubes, dimensions, user folders, etc.

Although it's not common this is easily done - since the cfg file tells you where the directory is, not vice versa. But without IT getting helpful I really can't see how you can progress the problem.

[LoadzaGrunt]

LoadzaGrunt wrote:
How sure are you that you have specified the correct username and domain in the UniqueId field ?

At this point, it's my #2 suspect, down from #1 two weeks ago.

My initial suspicion is that is your UniqueId field settings, or your Security package, or both.

Do a Start->Run->cmd

To find out the username your operating system is passing to TM1:

Code: Select all

echo %USERNAME%

To find out the user domain your operating system is passing to TM1:

Code: Select all

echo %USERDOMAIN%

The possibilities for the UniqueId field should then be either:
YOUR_USER_NAME@YOUR_USERDOMAIN
or
YOUR_USERDOMAIN\YOUR_USERNAME

AFAIK, NTLM needs the former syntax but Kerberos can work with both because Kerberos is a sort of upgraded NTLM.

At this point I would test Perspectives Integrated Login after a TM1 instance restart after having configured each syntax in the list:
1. SecurityPackageName=Kerberos and YOUR_USER_NAME@YOUR_USERDOMAIN
2. SecurityPackageName=Kerberos and YOUR_USERDOMAIN\YOUR_USERNAME
3. SecurityPackageName=NTLM and YOUR_USER_NAME@YOUR_USERDOMAIN
4. SecurityPackageName=NTLM and YOUR_USERDOMAIN\YOUR_USERNAME

As a precaution I would only do those tests after having confirmed (per the initial suggestions) that:
a) the TM1 service for your instance is running under the Local System account and the server (the box) is on the same domain as YOUR_USERDOMAIN
or
b) the TM1 service for your instance is running under a domain account from the same domain as YOUR_USERDOMAIN

Getting Perspectives working is no guarantee the other clients will follow along, but it is a step in the right direction.

HTH

[kangkc]

If you can afford to down the server to do a quick test, switch the SecurityPackageName to NTLM and try it. This may not solve it if you need to use kerberos for some reason but at least help to isolate the problem.

I have experience issue with Kerberos before and it get worse when I need to get TM1 Web running using Kerberos on a different box. There are lots of SPN issues and constraint with kerberos.

[highlnder8]

Encouraging News!!!!

I changed the UniqueID to domain\username and...I'm getting a new error related to the SPN! Progress!

I'm having my IT liason change our SecurityPackage from Kerberos to NTLM today and see what happens. Fortunately, we don't have anything active on our Dev server this week so taking it down isn't an issue. Hopefully, this will get applied in the next day or two and I can report back some even better news.

I'm grateful for all the assistance you all are providing!

REM

[kangkc]

A few other things before testing:

1. The unique id username@domain under NTLM works for me for a few install sites. You may need to play around with the unique id.
2. Make sure the server is joined to the domain (ie has a valid computer account in the domain tree). This is a must.

Good luck.

[Gregor Koch]

Hi
From what I found the syntax for the Unique_Id is different in Kerberos. No real proof for this other than it only ever worked once I changed the syntax.

If you use NTLM the normal windowsuser@domain (eg jsmtih@us) will do but in Kerberos the user principal name might have another syntax which is something like jsmith@us.ad.company.com

Never had to use the username\domain syntax nor did it work for me.

Check with your IT department and ask for the syntax of the user principal name for Kerberos and put that in the }clientproperties cube.

Cheers

[highlnder8]

SUCCESS!!!!!!

They changed the config file from Kerberos to NTLM. The UniqueID was left at windowsuser@domain.

Thank you EVERYONE for your contributions on this thread!! You helped far more and more quickly than the help desk at Cognos/IBM!

Again, thank you!!!
REM