SkipFire
asked on
TS Gateway configuration errors
I am trying to setup TS Gateway, however when I open the manager it does not load with my server name, and when I try to manually connect I get an error stating
The Terminal Services connection authorization policies (TS CAPs) cannot be read. This problem might be due to a corrupted store for the TS CAP. Alternatively, this problem might be due to a recent password change for the Administrator account on the TS Gateway server.
If I delete c:\windows\system32\ias\ia
When I do have it open if I try to create a new TS CAP I enter all the details and get an error stating "WMI failure: Unable to Create Network Access Policy".
How can I solve these 2 issues?
The Terminal Services connection authorization policies (TS CAPs) cannot be read. This problem might be due to a corrupted store for the TS CAP. Alternatively, this problem might be due to a recent password change for the Administrator account on the TS Gateway server.
If I delete c:\windows\system32\ias\ia
When I do have it open if I try to create a new TS CAP I enter all the details and get an error stating "WMI failure: Unable to Create Network Access Policy".
How can I solve these 2 issues?
ASKER
I am running WIN 2008 STD SP2
The ias.xml file can be deleted without me doing anything special, and gets recreated exactly as it should.
No services fail to start, no event log entries about TS or these errors.
I did remove AV as part of my troubleshooting and still get the error.
Nothing of interest in the security log, just log in and log off successes.
The ias.xml file can be deleted without me doing anything special, and gets recreated exactly as it should.
No services fail to start, no event log entries about TS or these errors.
I did remove AV as part of my troubleshooting and still get the error.
Nothing of interest in the security log, just log in and log off successes.
Have you tried enabling auditing on ias folder and ias.xml through file/folder security properties? Try auditing all actions for Everyone group successful or unsuccessful. Here are the steps:
If this is not a DC open Administrative Tools > Local Security Policy. Otherwise you will have to edit the settings of Group Policy.
Check the auditing settings for object access (usually it is disabled) like in the picture below.
To enable auditing right click the policy and open Properties. Set them as below.
Be sure to return this to default setting after you finish testing otherwise your security log will be filled up by various success/failure events. After clicking OK policy setting should loke like this:
After this locate the ias folder and setup audit for the folder and propagate settings to child objects. Right click the folder, choose Properties and open advanced security settings. Move to Auditing tab and click Continue to edit auditing properties.
Click the Add button and choose Everyone group and add Full Control for both sucess and failure events.
The auditing properties of ias folder should then look like this:
Repeat the attempt to access MMC with ias.xml in place (not deleted). If errors are encountered delete the ias.xml. Restart MMC, exit MMC, restart it again.
To minimize log impact disable auditing policy at this point. Now check your security logs. Events regarding file access have XMLs similar to this:
I hope this helps shed light on your problem.
Regards,
Tomislav
If this is not a DC open Administrative Tools > Local Security Policy. Otherwise you will have to edit the settings of Group Policy.
Check the auditing settings for object access (usually it is disabled) like in the picture below.
To enable auditing right click the policy and open Properties. Set them as below.
Be sure to return this to default setting after you finish testing otherwise your security log will be filled up by various success/failure events. After clicking OK policy setting should loke like this:
After this locate the ias folder and setup audit for the folder and propagate settings to child objects. Right click the folder, choose Properties and open advanced security settings. Move to Auditing tab and click Continue to edit auditing properties.
Click the Add button and choose Everyone group and add Full Control for both sucess and failure events.
The auditing properties of ias folder should then look like this:
Repeat the attempt to access MMC with ias.xml in place (not deleted). If errors are encountered delete the ias.xml. Restart MMC, exit MMC, restart it again.
To minimize log impact disable auditing policy at this point. Now check your security logs. Events regarding file access have XMLs similar to this:
I hope this helps shed light on your problem.
Regards,
Tomislav
ASKER
I already did that, no failures were captured, I did see a success entry for ias.xml
Sorry,
I thought you didn't have auditing activated.
So to confirm:
- you verified that and TSG can access ias.xml correctly
- you didn't detect any access to ias.xml other than your own and TSGs
- your TSG, NPS and WMI services are running correctly under default accounts (Network Service, Local System and Local System respectively) with no errors in system or application log
- there are no other relevant errors in System, Application, TSG-Admin and TSG-Operational logs
- your account is a member of local administrators on the machine and member of domain admins
I'm not sure where to go from here. I've usually had useful errors logged in system or TSG-Admin log and followed instructions at TechNet to resolve issues.
If your server isn't fully updated you may try that and also if all else fails try to reinstall TSG role.
Sorry I couldn't provide more help.
Regards,
Tomislav
I thought you didn't have auditing activated.
So to confirm:
- you verified that and TSG can access ias.xml correctly
- you didn't detect any access to ias.xml other than your own and TSGs
- your TSG, NPS and WMI services are running correctly under default accounts (Network Service, Local System and Local System respectively) with no errors in system or application log
- there are no other relevant errors in System, Application, TSG-Admin and TSG-Operational logs
- your account is a member of local administrators on the machine and member of domain admins
I'm not sure where to go from here. I've usually had useful errors logged in system or TSG-Admin log and followed instructions at TechNet to resolve issues.
If your server isn't fully updated you may try that and also if all else fails try to reinstall TSG role.
Sorry I couldn't provide more help.
Regards,
Tomislav
ASKER
All the assumptions were correct. I also have everything updated.
Trying to remove the TSG role fails.
Trying to remove the TSG role fails.
Hm,
failed uninstall of TSG role is new info. Did that produce any useful info about failure reasons in event logs?
After doing some Googling about this (I'm intrigued by the unusual :)) I found a somewhat bizzare note on one technet forum stating that changing the environment variable references for %TMP% and %TEMP% to %WINDIR%\Temp (usually C\Windows\Temp) solved the issues. But there was no confirmation on that one.
It's far fetched but... Temp folders are used during various installs. Machine and user environment variables point to different TEMP/TMP locations. So if the system ever tried to access user TEMP location it would need proper privileges. Normally LOCAL_SYSTEM has full access to Users folder and that wouldn't be a problem.
The only explanation I could figure in favor of the mentioned solution is that LOCAL_SYSTEM somehow didn't have the proper privileges to user's Temp folder. One reason for that is an actual error in ACL, and the other possible reason that the Users folder is mapped to a share on another server (and thus possibly inaccessible to LOCAL_SYSTEM). However, why it would only affect TSG is something that I can't explain. Also, I don't have the appropriate environment to test this.
Anyway, if you haven't figured it out by now you may give this a try but I'm not wildly optimistic.
Regards,
Tomislav
failed uninstall of TSG role is new info. Did that produce any useful info about failure reasons in event logs?
After doing some Googling about this (I'm intrigued by the unusual :)) I found a somewhat bizzare note on one technet forum stating that changing the environment variable references for %TMP% and %TEMP% to %WINDIR%\Temp (usually C\Windows\Temp) solved the issues. But there was no confirmation on that one.
It's far fetched but... Temp folders are used during various installs. Machine and user environment variables point to different TEMP/TMP locations. So if the system ever tried to access user TEMP location it would need proper privileges. Normally LOCAL_SYSTEM has full access to Users folder and that wouldn't be a problem.
The only explanation I could figure in favor of the mentioned solution is that LOCAL_SYSTEM somehow didn't have the proper privileges to user's Temp folder. One reason for that is an actual error in ACL, and the other possible reason that the Users folder is mapped to a share on another server (and thus possibly inaccessible to LOCAL_SYSTEM). However, why it would only affect TSG is something that I can't explain. Also, I don't have the appropriate environment to test this.
Anyway, if you haven't figured it out by now you may give this a try but I'm not wildly optimistic.
Regards,
Tomislav
ASKER
I did see the temp thing and tried that.
I wasn't able to find any informative messages from the failed attempts.
I wasn't able to find any informative messages from the failed attempts.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I have IIS with WSUS.
There wasn't anything logged aside from the error that was displayed for MMC or WMI, and I don't see anything related to the TSG removal attempt.
I thought that the TS CAP was required for TS Gateway to work but it is now working without any policy there. I'm going to do some research about the risks of not having one specified, but I didn't plan on using it to lock down anything anyway
Thanks for all the help.
There wasn't anything logged aside from the error that was displayed for MMC or WMI, and I don't see anything related to the TSG removal attempt.
I thought that the TS CAP was required for TS Gateway to work but it is now working without any policy there. I'm going to do some research about the risks of not having one specified, but I didn't plan on using it to lock down anything anyway
Thanks for all the help.
OK, good luck. After researching your problem it seems TSG install is much more sensitive than I thought. I've installed it in different environments so far and it didn't cause problems (even on SBS). Since I'll be using it in the future too for TS hosting applications I'll probably come across situation like this. If I do and manage to resolve it (I am a hands-on type) I'll let you know.
Regards,
Tomislav
Regards,
Tomislav
what specific OS version are you running? This seems like you're having problems with privileges to access specific folders on system drive.
Are there any errors in event logs or services failing to start?
Are you running AV software on the server? If yes have you tried the above steps with AV disabled?
Try checking security event log for any audited access failures to ias.xml or ias folder. If you dont have auditing set up enable it first through group or local policy and then configure specific auditing rules on objects you want to audit.
Regards,
Toislav