June 25, 2013 at 11:41 am
I wanted to find out for sure if what I experienced today with a password is a standard error or if something else is going on.
For a new user account the password was set with some alpha characters, a number and an "@"
The user could not log into the database from either application that was the reason for the user.
When the "@" was replaced in the password with another character the user could log in through both apps.
According to books online [see below] there are certain special characters listed that specifically cannot be used and there are examples of special characters that can be used. .... but the "@" sign is not listed in either set of characters.
So, my question is, would this be an application password limitation or a SQL Server login limitation?
Thank you for your insight!
FROM BOOKS ONLINE
Password complexity policies are designed to deter brute force attacks by increasing the number of possible passwords. When password complexity policy is enforced, new passwords must meet the following guidelines:
•The password does not contain all or part of the account name of the user. Part of an account name is defined as three or more consecutive alphanumeric characters delimited on both ends by white space such as space, tab, and return, or any of the following characters: comma (,), period (.), hyphen (-), underscore (_), or number sign (#).
•The password is at least eight characters long.
•The password contains characters from three of the following four categories:
◦Latin uppercase letters (A through Z)
◦Latin lowercase letters (a through z)
◦Base 10 digits (0 through 9)
◦Non-alphanumeric characters such as: exclamation point (!), dollar sign ($), number sign (#), or percent (%).
Passwords can be up to 128 characters long. You should use passwords that are as long and complex as possible.
June 26, 2013 at 7:34 am
I have the @ symbol for several service users and it works fine. I would assume therefore that the problem is an application problem and not the database itself.
The second reason I think that it is the application, is that when Windows Authentication is the means by which SQL Server is accssed, Windows acceptable passwords would need to work. The @ symbol is acceptable within Windows and therefore should also be acceptable to SQL Server.
June 26, 2013 at 7:47 am
@ is acceptable in both SQL Server and Windows passwords. In the case of Windows Authentication, SQL Server will never even be sent the actual password as authentication is offloaded to Active Directory. Sounds like an application issue to me. Something in between the login screen/dialog and the database server the application is munging the password.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 26, 2013 at 8:56 am
I've experienced this issue if the application is using a SQL login and the @ character is in the password. I could never get the application to connect properly so had to change the password (the application was running on a standalone legacy server so windows authentication wasn't an option)
June 26, 2013 at 11:24 am
Thank you all for the replies.
The applications do connect using a SQL login [integrated Windows login is not supported by the application]
It is good to know that others have experienced the same issue.
I changed the passwords and all is working correctly now. Just a quirk to remember.
June 27, 2013 at 2:15 am
Yeah, I think it was how the application was parsing the connection string to get the password, as I could connect with the same username/password combo fine in SSMS, but the developers of the application couldn't provide much input, so hence changing the password was easier.
June 27, 2013 at 5:41 am
Was it a Java app by chance?
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
June 27, 2013 at 8:43 am
It was MS Dynamics GP direct connection and the connection through Scribe GP adapter.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply