This may be covered in one of the thousand readme documents or elsewhere; however, I thought I'd share this here just in case it isn't or you don't want to search various PDF documents.
We recently had a user complain that he could not login to FDM anymore. He used to be able to login with no issues; however, recently it would not let him in.
To rule out system issues, we checked the following:
- Verified others could authenticate FDM with no issue (OK)
- Verified account unlocked in Active Directory (OK)
- Tested logging in to FDM on other machines (Fail on all machines ruling out cookies, browsers, etc)
- Checked Shared Services provisioning (To ensure he was indeed still provisioned for FDM)
- Attempted logging in through Workbench (Failed, but good fail. Did not state unable to authenticate, but properly noted he was not an Admin and therefore could not use Workbench. Wonder why it "works" here but not web....)
Since it was obviously not some type of system/account issue, we then checked:
- What end user changes happened recently? (Password change)
As the only recent change was the user's password change, I asked the user what the password changed to. The new password was pretty vanilla, though I did notice one potential issue in that it including the & character.
As many here will note, the & character doubles as a concatenation character in VB/VBscript. As programs should be escaping any strings they attempt to process, this should not matter; however, if FDM isn't properly escaping via the web login page this may be causing the issue. After resetting the user's password without the & character, everything worked fine.
So the moral of the story here is that apparently the FDM web login code behind doesn't escape the password string. The bad part is that it may prevent someone from logging in. The worse part is that this is a potential security problem since it may lead to code injection attacks.
If you want to prevent end user issues, you may want to remove the & character from your domain's password policy.
You may also be interested to know that using special character in the internal administrator id will cause issues on 220.127.116.11 and 18.104.22.168 actually documented the characters you should NOT use. See http://docs.oracle.com/cd/E17236_01/epm.1112/epm_deploy_guide_1112200.pdf
I have also seen issues with the internal admin password when it was > 25 characters which caused the shared services migration utility to fail.
The moral of the story is "secure" passwords dont' always play well with software. Which I could see being a problem in the 1980's. With the advent of Unicode and it's ilk it's sad to see that arbitrary text is not properly escaped. I know I"m ranting to the choir though Charles ;).
Yes it's amazing that there are still escaping issues and I do recall seeing the "characters not to use" document at one point or another. It does make your head hurt a bit. :)
The bigger looming issue; however, is the potential to exploit this from a security perspective. As we're wrapping up our year end close, I don't have the time to experiment with this more. Once we've closed our year out, I'm going to see if I can create any security holes using this as that might convince them to move past the "characters not to use" documents and perhaps start escaping things.