A client showed me this today, I don’t support their Sage, but I was on site and the people who do support their Sage (I wont name and shame one of our competitors), had told them it was their DNS server that was causing the error.
Logon Error
Loon failed due to unexpected error.
Please check if the Sage200Configuration database is configured and running.
(Message was: The remote server returned an error: (502) Bad Gateway.)
Solution
A couple of quick ping tests on the affected machine disproved the DNS theory! I thought it might be permissions as it didn’t error on my domain admin account. After some frowning, I though the error looked vaguely “web server” related and had a brain wave.
The affected client was set to web browse through a proxy server, as soon as I created an exception for the server that was running Sage, It started working!
Related Articles, References, Credits, or External Links
This problem was originally identified by Microsoft here. But none of the fixes recommended by them were really practical in my clients situation.
I did read one promising post that said, if you disable offline file caching by GPO this problem would cease. However this particular client HAD TO have that feature enabled (for Ranger Offline).
Someone else had written a PowerShell script that ran through and changed the permissions on the offending file (see below), but what about new users?
Solution
I’ve got three options either, setup an FSRM screen and set it to remove the offending file, use a group policy preference, or add the following to the users login script (or run as a script with GPO);
Option 1 – Remove Desktop.ini with Group Policy Preference
1. This is the file in question ‘desktop.ini’, it changes the icon and display-name of the folder (on Windows Vista and newer). You will notice the actual name of the folder does not change (see the example I posted above), which you can see by turning on the filename column in Windows Explorer.
Note: desktop.ini is a system and a hidden file.
2. I’m creating a GPP to remove the desktop.ini file. On a domain controller Start > Administrative Tools > Group Policy Management Console > Navigate to where you want to create your policy, or edit an existing one > Navigate to;
[box]
User Configuration > Preferences > Windows Settings > Files[/box]
Select New > File > Action = Delete > Source Files N:desktop.ini > Tick ‘Suppress errors on individual file actions’ > Common Tab > Tick ‘Run in logged-on-users’s security context (user policy option)’ > Apply > OK.
3. It should now look like this.
Option 2 – Use a File Screen
1. You need to have the ‘file services’ role installed, open the ‘Server and Storage Management’ Snap-in > File Group > Create File Group > Give it a name > Add in desktop.ini > OK.
2. Right click ‘File System Templates’ > Create File Screen Template > Give it a name > Select Active Scanning > Tick desktop.ini > OK.
3. Right click ‘File Screen’ > Create File Screen > Browse to the volume or Folder > Select your file screen template > Create.
Locate and Remove ALL instances of Desktop.ini
Download and run this PowerShell Script to remove all instances of Desktop.ini from a folder and subfolders.
Related Articles, References, Credits, or External Links
Seen on ARCServe 11.5 (SP2) when doing a brick level restore of user data.
Error: E8601 Failed to connect agent. (AGENT=dbaxchg2, EC=Invalid user ID or password was submitted or
Database Server instance may be inaccessible. If user ID is a Windows domain account,
please use DomainUsername.)
Solution
Assuming you have the correct credentials set up in ARCserve server admin, and in the ARCServe Exchange agent, Attempt to re-run the restore job, at the final stage you will be presented with the “Session User Name and Password” dialog box. Select the job > Click Edit > Enter the credentials as DOMAINNAMEusername with the correct password > OK.
Then select the DBAgent tab, and do the same on there.
The Restore should now proceed.
Related Articles, References, Credits, or External Links
To save you creating multiple users on your FireSIGHT appliance, and assigning roles to them you can utilise your existing Active Directory. In fact FireSIGHT does a good job of enabling granular administration based on AD Groups, by assigning them to ‘roles’ on the appliance.
Below I’m just going to create one AD group and assign the administrator role to that group,as you would in a small organisation. but I will point out how to enable RBAC on the appliance.
I had to work out how to do this, because the official documentation just does not work? Or at least it did not work for me with my 2012 R2 domain controller.
Solution
1. Log into FireSIGHT > System > Local > User Management > Create External Authentication Object.
2. Authentication Method = LDAP > Name = Something descriptive > Description = {optional} > Primary Server IP = IP of you Domain Controller > Port = 389.
Note: If you change the authentication method below to SSL the port will automatically change to 636 (LDAPS).
3. Enter a secondary domain controller IP if you have one.
4. In my AD I’ve created a user for the appliance to connect to AD with (svc_sourcefire), and a group called Sourcefire-Admins that I’ve put my administrative users in.
5. In the FireSIGHT console you have to enter domain objects by their DN. If you’re unused to using DN notation, on the domain controller run LDP (Connection > Connect > Server=Localhost > OK > Connection > Bind > OK > View > Tree > OK) In the left window you can expand and navigate up and down your domain tree. When you find th group/user you want right click copy DN, Then you can paste it into FireSIGHT without having to write it out.
6. Set the Base DN (usually the root of the domain) e.g.
[box]DC=petenetlive,DC=com[/box]
Enter the DN for the user the appliance will use to bind to Active Directory, e.g.
Enter the user (above) password. Set the UIAccess Attribute and the Shell Access Attribute to;
[box]sAMAccountName[/box]
Note: The drop down arrow unlocks the advanced options if you wanted to use LDAPS then this is where you would select it and upload the root CA certificate.
7. Expand Group Controlled Access Roles (Optional) > Enter your AD group against the role you want to assign to it e.g.
Note: These are the built in roles, you can clone and create new ones. (System > Local > User Management > User Roles).
Set the Default user role to ‘Security Analyst (Read Only)’.
8. Group Member attribute = member > Shell Access Filter = ‘Same as Base Filter’ > Username enter an administrative username form the group you specified above > Password = password for the user you are testing > Test.
Note: Shell Access Filter wont actually do anything in this instance.
9.You will get a lot of info, but hopefully you will see ‘Success’.
10. Now you need to use this authentication method for the appliance. System > Local > System Policy > Select the policy in use > Edit, (pencil icon).
11. External Authentication > Status = Enabled > Default User Role = Security Analyst (read Only), No I don’t know why you do this twice > Change the ‘slider button’ to enabled > Save Policy and Exit.
12. Because the policy has changed and not updated > Update.
13. Select All > Apply.
14. Success.
15. You can not log in with your administrative AD accounts.
16. You will also notice the users appear under local user management > Users.
17. You could, (if you wished) Untick the ‘Use External Authentication Method’ option and turn this user into a ‘local’ user.
Related Articles, References, Credits, or External Links