Tam 11/Terminal Service Bug

Started by cgrasso1, June 06, 2013, 02:38:43 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

cgrasso1

We have TAM running on a Terminal Server 2008 R2, and for some reason that server is not applying TAM security. Our producers cannot alter current applications, and when a producer logs on in the office, sure enough they can't.  However, when they connect through terminal services, they can.  Applied has no official answer....

Thanks

Jim Jensen

Welcome to AU, is it Chris? That seems really odd, but I'm no terminal server tech. I'll let others with more knowledge chime in, but wanted to at least welcome you to some new, but possibly familiar grounds.
Jim Jensen
CIC, CEO, CIO, COO, CFO, Producer, CSR, Claims Handler, janitor....whatever else.
Jensen Ford Insurance
Indianapolis

cgrasso1


Bob

We do this just fine..  Not TAM..  Would think either security/rights/GPO.   Hard to tell but nothing to do with TAM that I can confirm.  Many of us are doing this.

Through trial/error and feed back some might be able to help you identify problem.   Can confirm it is not TAM issue.

Welcome to AU!  :)

Mark

Are the producers logging in with the same TAM credentials on the terminal server vs. their desktop in the office?
Mark Piontek, MBA
Director of Information Systems
BS in Information Systems Security

Mark

Quote from: Bob Connor on June 06, 2013, 02:53:23 PM
Can confirm it is not TAM issue.

Sure sounds like a TAM issue to me, Bob.  TAM security settings are done via TAM -- NOT windows...  Can you elaborate on why you think it's not a TAM issue?  We are also running 2008 R2 Sp1 TS without this issue.

I need an example to accept your confirmation!  8)
Mark Piontek, MBA
Director of Information Systems
BS in Information Systems Security

Bob

Because I can do it!   ???

Many using that setup besides me so another reason..   Using bugging 11.0 version.   :)

If I can and other can you can, can't just be a tam issue can it?  My logic!

Mark

Well, my logic was that TAM security settings have nothing to do with Windows Server at all, so how could it be a windows server issue? Must be something wonky, like TS is not pointing to correct TAM db or something else TAM related.

Does TAMSTART check out?
Mark Piontek, MBA
Director of Information Systems
BS in Information Systems Security

Bob

That's just it, I'm a bit lost on question can and can nots.

If they can on site, and can't offsite, then something over looked.  Makes me think server whether configuration/security..  I can't pin point without more feedback as again unsure the question as presented.   Can remotely but can't in house or is it can in house but can't remotely?   I can say not TAM because MANY are doing so without this problem.  :)   Not to say TAM is less than perfect app.

Conan_Ward

Quote from: Mark on June 06, 2013, 03:26:15 PM
Well, my logic was that TAM security settings have nothing to do with Windows Server at all, so how could it be a windows server issue? Must be something wonky, like TS is not pointing to correct TAM db or something else TAM related.

Does TAMSTART check out?

Either it's not pointing to the same data or its not the same credentials, for better or worse, TAM doesn't use Windows security and Windows security doesn't have a way to block edits to an application. Unless they're getting some sort of windows error/tam exception error citing access is denied (i'm assuming not and assuming they use the same domain credentials on both TS and workstation).
Former TAM support, P&C licensed in Maryland, LFW

Mark

I'm with Conan on this.  We'll need more details.
Mark Piontek, MBA
Director of Information Systems
BS in Information Systems Security

Bloody Jack Kidd

Is there only a single instance of TAM in the environment? As in, no test / dev etc.

If g: h: got mapped to some other TAM instance with alternate security settings, this could happen.
Sysadmin - Parallel42

Jeff Zylstra

Hi Chris, and welcome to AU!  I didn't see if this was a new TS installation, if this just started happening, or just what the timeline of events was here.  My guess however, is that a quick run though of the TAM installation steps for Terminal Server will produce a Homer Simpson-like "Doh!" moment where something simple but important was missed or mis-configured. 

I don't know if the "SET" command at a command prompt of different user logins would show drive mappings and environment variables for these users or not, but it's quick, easy and free.  My 3 favorite things!  Let us know what you find. 
"We hang the petty thieves, and appoint the great ones to public office"  -  Aesop