No change in any scripts and it works by magic!

Even a ipconfig /flushdns with browser clear cache - MSIE and FF - on intranet (VPN) and on WAN redirection from Nettica earlier did not solve the issue earlier.

The question is how does a CSRF attack get manifest in the FA code to work at the will of an unknown hand?

All other fields can be changed without any errors in both default and non default companies.

Setup -> User Accounts Setup -> Edit Any User

The $_SESSION['csrf_token'] is different from the $_POST['_token'] and hence the function check_csrf_token() in line 67 of includes/ui/ui_controls.inc fails.

This means that the session variable gets restarted on the end_form() function that generates a new session which seems to jump the gun.

Also the db schema default value for the print_profile field in the users table should be blank instead of 1 as it stores a string value of the profile name when assigned.