Is there any way to obtain (not change) the password of the ASPNET account on a Windows Server 2003 server? I need to snyc my workstation's ASPNET account password with the one on the server I am trying to connect to.
I am trying to trouble shoot the following issue with my ASP.NET application.
There is a simple way to obtain this password. This account is auto created so its not as simple as "Asking your network administrator".
First dump the password hashes from your domain controller, most anti virus will see PWDUMP has as a virus so be sure to disable AV before you run.
Second after you dump these passwords feed them into John the Ripper (note: John the ripper is not the best program to use to do this, but it does happen to be free)
Here is a (somewhat out of date) tutorial for breaking passwords with John
The only way to obtain an NT service account password is to ask someone who knows. If the person who ought to know doesn't then that same person ought to be able to reset it for you. In other words you should probably talk to your network administrator.
Essentially No there is no way to retrieve a windows account password. You can change them with various tools but retrieval is highly unlikely.
You can always create a proxy account on a domain controller and setup an app pool to run under a proxy account so permissions can span across workstations.
Related
A client requested that we develop a site for them but instead of the standard ASP.NET authentication or using Active Directory accounts, they would like us to use SQL server accounts for authentication. (That is, an account using SQL Server authentication.)
This website would be exposed to the public Internet and would have users that are not employed by the client and the client's Active Directory is not available in their DMZ.
So I have a few questions on this:
1) Is this a good idea? (Our gut feeling is that it's not.)
2) How should we best go about doing this?
Off the top of my head, the best answer I can come up with for how to do this would be to dynamically build a connection string based off the credentials the user enters in a web form. If the connection is successful, continue to the site. Otherwise, kick them back out to the login page. (And, of course, make sure accounts get logged out in the event of too many failed logins.)
Is there a better way?
Thanks.
1) Is this a good idea? (Our gut feeling is that it's not.)
There are a few problems using this. Notably, you would have to run your application as an escalated user to perform user maintenance-- add/inactivate users, change passwords, etc... Running a web-app with escalated permissions on the database is generally frowned on. If you run this kind of thing outside of your application, then you'll need to get your DBA to run all the user maintenance stuff, which isn't fun. Also, if you have requirements around password complexity, password rotation, etc., you may find SQL Server authentication lacking over what would be available in AD, for example.
2) How should we best go about doing this?
You can easily test credentials provided by attempting to login to SQL Server using the supplied credentials. You can read the connection string from your configuration settings, but then load it into a SqlConnectionStringBuilder object (in System.Data.SqlClientsomewhere), manipulate it to use the supplied credentials, and then connect using the result of that manipulation to test if the credentials were valid.
You would want to use that only for testing your login. After that, you could go back to using your normal connection strings.
I use Windows Authentication with a load balanced website. The load balance is based on two IIS web servers. There is a feature in my site which allow users to relogon like Sharepoint sign-in as different user.
But I notice that while I relogon, the User.Identity in one site is changed but the other site still keep the prior account.
I suspect there are something in the cookie should be clear.
Has anyone faced this problem while playing with loading balance? Or do you know some related article which might help?
I don't know how to fix the problem. Any help will be appreciated.
by the way
I use this method to archieve the relogon it works on single server. http://www.roelvanlisdonk.nl/?p=825.
Hello guys,
I still work on this feature.
I print the User.Identity.Name in my home page. when I change the account, the User.Identity.Name output is changed correctly. but when I refresh the home page, sometimes the prior account will be displayed on the home page.
If I'm reading your comments correctly, your setup involves two web servers, each with a local user with the same name (and presumably the same password), and you're attempting to use Windows authentication in the web farm scenario.
In your situation, each computer has it's own account with a name - assume your username is "AuthorizedUser". Bear in mind that if AuthorizedUser is a local account on both machines, then these are two completely different user accounts. Each computer checks it's own user account information to verify the identity of the person, and in a non-Domain situation, Computer A has no reason to trust a user that was authenticated on Computer B.
If it were possible that computer A trusted computer B without a domain scenario - just two random computers that happen to have a user with the same name, imagine how easy it would be to hack into anyone's web server that's using Windows Authentication. All you'd have to do is guess a valid username, rather than a valid username/password combination. It's easy to see why this is a bad idea.
For Windows Authentication to work in a web farm scenario, you need to be using a Domain user (A Windows NT Domain) and that Domain User needs to have the same permissions set up on two servers. This way, there is only one AuthorizedUser, and both web servers can verify the identity against the domain. Both web servers will automatically trust that the Domain Controller has authorized the user properly and will trust the domain.
I'm looking at starting a new web app which needs to be secure (if for no other reason than that we'll need PCI (Payment Card Industry) accreditation at some point).
From previous experience working with PCI (on a domain), the preferred method is to use integrated windows authentication which is then passed all the way through the app to the database using kerberos (so the NT user has permissions in the DB). This allows for better auditing as well as object-level permissions (ie an end user can't read the credit card table).
There are advantages in that even if someone compromises the webserver, they won't be able to glean any/much additional information from the database. Also, the webserver isn't storing any database credentials (beyond perhaps a simple anonymous user with very few permissions for simple website config)
So, now I'm looking at the new web app which will be on the public internet. One suggestion is to have a Active Directory server and create windows accounts on the AD for each user of the site. These users will then be placed into the appropriate NT groups to decide which DB permissions they should have (and which pages they can access).
ASP.Net already provides the AD membership provider and role provider so this should be fairly simple to implement.
There are a number of questions around this - Scalability, reliability, etc... and I was wondering if there is anyone out there with experience of this approach or, even better, some good reasons why to do it / not to do it.
Any input appreciated
Having used ADAM in a project, I found it to be bear. Documentation for developers can be sparse, it has quirks that differentiate it from full AD and, most importantly, I could not get a straight answer from MS as to whether it will be fully supported in the future. The impression I got was that ADAM was the bastard child and that the new Federated services (ADFS) was where they wanted people to go. Just moving the ADAM store from one member server to another was a pain. Now that said, my issues with ADAM had to do with development against and maintenance of the store, It definitely has the ability to scale and it was reliable. That said there are times when you need to delve into 80th level spells of LDAP/Directory magic to figure what it is or is not doing.
For a public facing site, AD/ADAM might be overkill IMO. You could use alternate MembershipProviders like the SqlMembership provider to get the good level of security with respect to credentials. If you wanted to go further, you could use database encryption (SQL Server at least has this ability built-in) to encrypt information that falls into the PII (Personally Identifiable Information) arena and of course encrypt the backups. The advantage that a database backed authentication store has is that you have all the tools that your database product provides to scale out, do backups, control access and so on.
EDIT: Let me add, that with .NET you can setup your site so that it runs under a Windows user and connects to the database using Windows Authentication (assuming the db supports it). Thus, no credentials need to be stored in a config file. However, if you had to store credentials for whatever reason, you can then use DPAPI to encrypt the credentials in the config file.
ADDITION In response the question about securing encryption keys you have a couple of choices. The first is to simply hash the credit card numbers. That greatly simplifies any problems with access to the data however, it means that the customer would have to re-enter their card number for each purchase. If you want to remember the customer's card number, then you move into a new realm of maintenance of the decryption keys. In this scenario, you absolutely should use Windows Authentication to the database and look into SQL Server 2008's Extensible Key Management feature which lets you hook-in a third-party key management program into SQL's encryption functionality. In this way, only the website user would have access to the keys used for decryption. There are other solutions to ensure that the website cannot be compromised. The greater worry is that someone gets a copy of the database undetected. Here's a link on using SQL Server to be PCI compliant:
Deploying SQL Server 2008 Based on Payment Card Industry Data Security Standards (PCI DSS) Version 1.2.
couple ideas
Run AD/AM - Active Directory Application Mode.
It scales well. It's the same core code as AD. Similar management capabilities. Solid reliability. Works with the ASPNET AD Membership Provider.
And it's included in Windows.
Also consider exploring a federated identity system, via ADFS 2.
unlike AD/AM, this approach is fairly leading-edge. The final version of the ADFS v2 server is not yet available from Microsoft, but it is at "release candidate" stage. If you have the stomach to be an early adopter, ADFS2 holds the possibility to employ a federated identity approach. That means you could accept identity tokens from a variety of existing sources: a google sign-in, a yahoo sign-in, any OpenId source, and use that as the identity on your site. Users would not have to "register" and authenticate to you. Instead, your site would honor the identity and authentication provided by some trusted third party, and perform authorization based on that identity.
This is not a direct answer but having a AD user account means you need a windows CAL for that user. Another way would be to issue client certificates to user and map client certs to AD users in IIS.
You might also consider AzMan with SQL store available from Windows 2008 onwards or the open source netsqlazman.
I need to implement application that supports LDAP authentication.
I want to know in detail how such network works. Can you recomend some reading about it, a book perhaps with broader explanation of LDAP authenticated networking or at least some online tutorials. I would like to see step by step guide of creating such network and if possible, cross platform theory with samples in Win and *nx systems.
Thanks.
LDAP System Administration is the book I read when I first started with LDAP.
That and the OpenLDAP Administrators Guide.
In addition to gacrux, I'd suggest looking at
Lightweight Directory Access Protocol (Wikipedia) for an introdcution
LDAP Linux HOWTO by Luiz Ernesto Pinheiro Malère
Understanding LDAP (part 1) and Understanding LDAP (part 2) on devshed.com
LDAP and OpenLDAP (on the Linux Platform) slides
Are you looking to build new LDAP server infrastructure, or are you looking to use an existing service?
If you're building infrastructure, then Understanding and Deploying Directory Services has long been the book to get. It clearly explains what LDAP is, how to design your schema and directory information tree layout, and how to choose an appropriate directory topology.
If you're trying to authenticate users against an existing LDAP service, you would be best served by reading the library docs for your language. The typical process for authenticating users goes like this:
Take the user's user id and search against LDAP for that user to obtain the disinguished name (or DN, a unique name for each entry in the LDAP tree).
Use the retrieved DN and the password the user provided to "bind", or authenticate against the LDAP server as that user.
Check the return code from the server to determine whether the bind was successful.
Based on the results of the previous step, allow or disallow the user.
For my asp.net website with forms authentication, I will use Windows integrated security to access a sql database. I will give DB permissions to the ASPNET or NETWORK SERVICE. Under what circumstances would I use SQL authentication instead?
SQL authentication is also often required when your site is being hosted by an external ISP. They often do not support windows authentication or do not allow you the ability to grant permissions to windows accounts.
Use SQL Auth when you need non-Windows machines to make a DB connection.
Keep in mind that it adds another attack vector (another set of credentials to compromise the machine), so make sure you really need it before using it.
Really you use SQL Authentication when you can't use Windows Authentication. In my opinion that is about the only time. Windows authentication is more secure and can be centrally managed in places which use Active Directory. If you have people who really know how to adminstrate Active Directory and you're in a windows environment, there isn't a good reason to use sql authentication.
With Sql Authentication you have to manage the passwords etc in connection strings and that means that in order to change the account accessing the database, someone has to know how the application functions or at least where the information is stored. With Windows Authentication, all the network admin has to do is enter in the correct username and password into the IIS application settings and you're ready to rock and roll. No developer interaction required.
You have extra steps in securing the connection string information as passwords etc. should be encrypted when stored in the config files. All around there are a lot more steps in invovled in efficiently and securely using Sql Server authentication as opposed to Windows Authentication. This is espcially true if the same sql server credentials are used to access multiple databases across multiple servers.
If you want to completely manage user accounts, you should use SQL Authentication.
This way, you have complete control over user accounts. You could force them to enter private information for example.
Also, like Corbin mentioned, if clients are not running windows OS, you cannot use Windows Authentication (obviously).
Please be reminded that Windows Authentication is the recommended mode of authentication for the simple reason that it inherits the OS authentication. There are many factors that you may not use Windows Authentication as explained above.
That depends. If you are developing a in house web app and the network IT people are down the hall then use Windows authentication. If you are deploying your app to customers and you have no control of their network infrastructure then I would use SQL authentication
If you don't have control over the Active Directory (Like in a hosted situation) or there are users with operating systems other than Windows, you don't have a choice.
Is there a need to create user accounts on the fly with some script? It has to be easier to do for a sql user than the Active Directory (Probably not impossible).
Besides all of the above, consider a case like this:
The account you need to use is from Domain A.
The database is on Domain B.
Domain A and Domain B dont have a trust relationship.
You will need SQL authentication to get past this situation.
Hope this helps.
(To add more clarity): The database is NOT registered with the active directory. Then it is not posisble to use windows authentication.