TS RemoteApp Authentication Issues


I have a single Windows Server 2008 R2 server that is hosting both my TS Gateway and TS RemoteApp.  The server sits in a DMZ and appropriate firewall rules have been added to allow communication in and out (both directions). The server is part of the local domain that our entire enterprise is running on.

The application that I am trying to host is IE and users will access websites that sit outside of the DMZ.  The reason for the DMZ is added protection from other websites and applications and data that should not be accessed.

I have created a separate OU for users that will only be allowed to access this server (Active Directory "logon to" settings).  These users do not have administrative privileges but they are capable of logging onto this one box (I have checked this).  They are part of the remote desktop users group on the local box.


All users within the domain (including users mentioned above) can log into the RDWEB connection.  Once in each different type of user can see that correct remote apps that they can launch.  Once I click on the application it launches and the user is prompted to enter their user name and password (with domain).  Three scenarios occur here:

1) If domain admins put in their user name and password they are capable of launching remote applications and everything runs fine.
2) If normal domain users put in their user name and password they get a message prompt that says your account is not allowed to connect remotely (this is disabled by GPO for a reason so I don't expect this to work).
3) If a user that is within this new OU mentioned in setup section above uses their user name and password the local security log on the server shows EventID Error 533 of Type 3 (Network).  The remote application never launches because it continues to say invalid user name and/or password.  The authentication prompt appears over and over again until you select cancel.  There is no other error or message that shows up...and I have been unable to find a solution to this problem.

Any ideas on how to solve this?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Spike99On-Site IT TechnicianCommented:
I think we'd need to have more info to determine what's going on. I think it would be helpful if you could post the text of one of those Event ID 533 errors.  

Is the GPO that allows users in the problem OU to log on remotely restricting their logon to particular servers?  I googled that error and I found many posts that say that the event id 533 is caused by a user attempting to log on to a system that restrictions bar them from logging on to.  The text of the error could help us figure that out.


keyurpatel83Author Commented:
I cannot send an actual screenshot because there is no way to get it off the system but I will re-type the contents that I am allowed to send..and since I don't have remote access to computer from home I will have to get that information tomorrow morning and post it to this forum

As for the other part of the question:

Currently there is no GPO inherited on the problem OU.  The only restrictions applied to all users in this OU (by individual user name) is what network resources they are capable to log on to.  Each of the users in the OU are only allowed to log into the particular server and nothing else.  I ran a few tests today to see how this behavior was functioning:

Test 1: I used my user account in the OU to RDP into the server in the DMZ (from the inside) and there were no issues, which means that using regular RDP over 3389 worked fine.  My user account was in the local remote desktop user group.
Test 2: I used my user account in the OU at the physical server and there were no authentication issues.
Test 3: I used the same user account and tried to logon to another workstation on the domain and I received an error message that basically said my account policy denied login to this asset.

Based on these tests the logon to functionality is working.  I then logged into RDWEB with my user account in the same OU and there were no problems; IIS accepted the credentials (there was never a problem with this).

Test 4: Once logged into RDWEB, I clicked on the RemoteApp and when asked for credentials I tried two different things:

a) My local admin account on the box using ServerName\admin and password.  This allowed the connection to be established.  From this point forward, the RemoteApp session started up and I was able to select logon as different user from the Windows login prompt and put my troubled OU account and password and everything worked fine.  The problem here is that I cannot do this for every user that will be logging into the system.

b) My troubled OU account, which continually prompted me for bad credentials and asking me for another user account and password.  This is what generated the Event 533 errors.
keyurpatel83Author Commented:

So I was mistaken about the error code number.  The 533 is what was reported to me by my coworker.  I went into the system and looked myself and this is the information I received:

Audit Failure Microsoft Windows security auditing.

Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: (fqdn of server)
An account failed to log on.

Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: (my acct name)
Account Domain: (my domain)

Failure Information:
Failure Reason: A user not allowed to logon at this computer
Status: 0xc000006e
Sub Status: 0xc0000070

Process Information:
Caller Process ID: 0x0
Caller Process Name: -

Network Information:
Workstation Name: (workstation name)
Source Network Address: (workstation ip)
Source Port: - 19089

Detailed Authentication Information:
Logon Process: NTLM SSP
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0 .
Protecting & Securing Your Critical Data

Considering 93 percent of companies file for bankruptcy within 12 months of a disaster that blocked access to their data for 10 days or more, planning for the worst is just smart business. Learn how Acronis Backup integrates security at every stage

Spike99On-Site IT TechnicianCommented:
Is there anything in the local or domain policy that would prevent the user from logging on to that particular server?
keyurpatel83Author Commented:
The local policy is to allow users to log into the particular server (the user is part of the Remote Desktop Users group and local policy is to allow Admins, Domain Users, and Domain Admins to logon to the box).  I tested this by logging into the server directly and using mstsc RDP to connect via workstations on the inside interface of the firewall (correct rules in place).
keyurpatel83Author Commented:
From some Googling I found that there was a known issue for the "Logon to" property in the user account information.  The issue states:

Either you have to include the client machine name too in the "Logon to" list or clear out this property. You can manage access to limited computers for a particular user using the TS Gateway RAP policy instead.

I was wondering if anyone knew if this really is an issue?  I will make the change, giving it some time to replicate, and see if this really is the solution to the problem.  I cannot put the client workstation name in because the people who will be connecting to RemoteApps will come from external burb on firewall and will be coming from a multitude of networks (meaning I will never know all of the workstation names).
keyurpatel83Author Commented:
I made the change to the user accounts in Active Directory and removed the logon to restrictions.  After some time (replication) the user was able to login through the RD Gateway.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
keyurpatel83Author Commented:
I found the solution with other information obtained from the server and the internet.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.