May 18, 2012 at 1:00 pm
Generally, I do my best to never let a SQL login have any sort of elevated privs on a database let alone the server.
Same here, which is why I'm not too stringent with the password. I abide by the OS enforced company policy of some combination of letters, numbers, and mixed case even though I could override that if I wanted. I specifically don't use "user must change password at next login" because I want to retain the credential. I store these in an excel file in a secure spot on my own machine but I suppose that could be done better by using a password vault.
Since we're physically spread out, handing it to them is not an option. Instead, I'll send the username in 1 email and the password in the next with the instructions "read then burn" 😀
Ken
May 18, 2012 at 1:12 pm
Henry_Lee (5/18/2012)
For those of us that find things like password length interesting, have a look at the page below. This guy is a great security researcher and this is an super clever approach to passwords. Be sure to read the entire page.
May 18, 2012 at 1:39 pm
I dealt with GP years ago. Through some SQL traces and calls with GP support, we determined that the app needs sa for new logins and potentially new databases. However if those are setup by a DBA, the app picks them up. We removed sysadmin from the app logins and they would call us when they needed a new login added.
Great tip. Had not thought of doing that. Thanks a lot.
May 18, 2012 at 5:32 pm
Steve Jones - SSC Editor (5/18/2012)
sebmr2 (5/18/2012)
All in all, this has worked well for us. Only problem is it leaves a physical copy of the password in the hands of the developer which may not be best.Does this password change between dev and prod (and qa)
Yes, we change the password for every environment.
May 18, 2012 at 6:06 pm
We use only Windows Authentication. New user are provided a Strong Password to start and required to select a new Strong password at first log on. Their rights are limited to their day to day activities. If they need elevated privileges then they fill out a change request that is then approved by multiple departments before the elevation is done. Once the task is completed their privileges are returned to their normal levels.
May 21, 2012 at 8:31 am
For users an AD account must be used. I have yet to have an issue with this.
For service accounts that MUST be sql logins, I use randpass.com and go to advanced. If this is from a windows system I set the generation size to 32 characters, and allow all characters and types (such as symbols). If the connection is from a unix/linux/open system I make it 16 characters with the same character set including symbols as I've found that most of the software used on those systems can't have a password longer than 16 characters :crazy:
May 21, 2012 at 11:35 am
Frank W Fulton Jr (5/18/2012)
We use only Windows Authentication. New user are provided a Strong Password to start and required to select a new Strong password at first log on. Their rights are limited to their day to day activities. If they need elevated privileges then they fill out a change request that is then approved by multiple departments before the elevation is done. Once the task is completed their privileges are returned to their normal levels.
The only problem(s) with that is this:
Many times you have to support older applications and applications provided by third parties that require SQL Server Authentication.
Many times you have to support environments with mixed operating systems, where all users are not authenticated by a Windows domain.
Sometimes you need to allow users to connect from unknown or untrusted domains. For instance, an application where established customers connect with assigned SQL Server logins to receive the status of their orders.
Sometimes you need to support Web-based applications where users create their own identities. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply