How can I automate the creation of a user in IIS7?
I'm using C#. I have code that automates the creation of a website, and I found some examples for automating the creation of an FTP site.
I also need to automate the creation of a IIS user for each FTP site that I create.
I could possibly just edit the administration.config file, under I could just add another element for each new user, but I wouldn't know how to set the password attribute, which is encoded. Plus, there's gotta be an easier more reliable way to do this.
The FTP users that I need to set up are not associated with any website. These users will only log into the FTP site, not into any website.
To manually add a user, I can run the feature "IIS Manager Users", then simply click on "Add User..."
This adds an entry to the config file, as I mentioned in my original post.
I then associate that user to my ftp site by adding an FTP Authorization Rule for that user.
As for my current configuration... On IIS7, under Management Service, under "Identity Credentials" I selected "Windows credentials or IIS Manager credentials".
For adding the users to Administration.config you can use the API in Microsoft.Web.Management.dll ManagementAuthentication.CreateUser, the following blog shows how to call it from POwerShell: Link
To add the FTP Authorization Rule you can use Microsoft.Web.Administration.dll. See: http://www.iis.net/ConfigReference/system.ftpServer/security/authorization for an example on how to do that.
Also consider using Configuration Editor to generate the code to automate changes to IIS configuration.
http://blogs.iis.net/webdevelopertips/archive/2009/01/11/tip-42-did-you-know-configurationeditor-allows-you-to-generate-c-javascript-or-appcmd-script-to-update-configuration.aspx
The answer is to use:
Microsoft.Web.Management.Server.ManagementAuthentication.CreateUser(userName, password);
This method will encode the password for us.
Related
Do you know if there is a way to disable the only verified custom domains usage when new create a new Azure Active Directory user.For example i want to create a user that is using gmail. I have tried to add gmail as custom domain and verify it, but noticed that the steps are related to the dns records of the domain so i cannot do this. I know i can use the invitation service, but i want to directly to create the user without invitation. So did someone experienced this, and if soo i am open for advices.
Have a nice day and stay safe.
It is not possible to create a user in Azure Active Directory that is using Gmail. In order to create a user in Azure Active Directory you need to add your domain and verify in Azure Portal.
You need to get your domain name by Go daddy etc... then you need to add in Azure Active directory and verify it. After that you can create a user name under that domain.
I recommend you to go through this two documents to get more detailed information.
I'm using VS Online Monaco; trying to figure out how to add users to my Azure web site so they can edit in Monaco. Adding them to the VSO group didn't work.
the Monaco editor is actually a site extension on your normal website, you actually use it through your webpublish account credentials, so it's actually not something you can easily override i think
Our environment is Sharepoint 2010, with a web application created (and site collection on top), using claims based authentication. The first site is using port 881. It is using integrated windows authentication. Another web application is created, extending the first application, using port 882. This site is using Forms Based Authentication, the membership provider is System.Web.Security.ActiveDirectoryMembershipProvider, named admembers. I have turned off Client Integration on both sites.
When I login to the 881 site, on my corporate network, logged into the machine with the same domain account that sharepoint uses, I can open an Office file saved in a document library, and it subsequently opens in the appropriate Office application, without asking me login again. But, If I login to Sharepoint from a computer that is not on our network, or login to the computer with an account that is not a domain account, I get prompted again to login when openning an Office document. If I choose the option to save, it does not prompt, but if I choose open in the dialog window, I am forced to enter my domain credentials again.
When I login to the 882 site, which uses FBA, I experience the same problem. If I open an Office document, the appropriate Office application opens, and asks me for my credentials, by showing me a dialog window with the sign in page loaded. If I choose to save the file, then I am not prompted to login, and the file saves to a local folder.
I can't expect my users that are off site to login again everytime they open an Office document, like Work, Excel, Powerpoint, etc. I have tried numerous fixes, including disabling client integration, changing the browser handling mode (strict/permissive), changing internet explorer settings (for integrated windows authentication), changing the integrated windows authentication site to use basic authentication, even hacking the page using jquery to call the sharepoint javascript function that execute the "download a copy" function. None of them work: when choosing to "open" the Office document in the browser, the user has to login again, or just close the dialog window without logging in (as long as client integration for the zone is turned off).
I'm looking to get this accomplished using windows authentication or forms based authentication.
Help!
I found this answer in a similar post which seemed to fix the problem for me when I tested it. The gist of it is you need to deny the HTTP Verbs OPTIONS and PROPFIND in IIS. Having said this, I'm not an IIS guru and am not exactly sure what this means or what else it might affect. Can anyone else shed some light on this?
A bit of background, I'm using SharePoint 2010, on an FBA site.
You have the standard three use cases:
Employee intranet access
Employee remote access
Partner remote access
Employee intranet access
This normally always works out of the box, and it looks like it is working for you.
Employee remote access
The only way that i have seen this work (and i have tried many ways) is to get TMG or ISA. Basically ISA is setup in FORMS auth with SSL, it captures the auth details, and then passes them to the sharepoint server. (and other servers if you have them eg OWA for sharepoint mail web parts)
If you select the "Is private computer" option on the ISA login screen, then Office documents share the auth cookie and don't prompt for another login. I had so many problems, but as soon as i installed TMG, they all went away. I would not recommend any other approach now.
The added bonus of this method, is that remote employees are treated as the same account as the intranet user. The way you are setup with a seperate web application, means that they will be different accounts, so things like [checkout/modifiedby/createdby/personalisation] will be different accounts (though they look the same)
Partner remote access
This may never ever work on some clients (especially Vista), as IE needs to share the authentication with Office
If this is sharepoint 2010, try this.
Get-SPSecurityTokenServiceConfig
Look at your UseSessionCookies value in the output. If True, apply the powershell below.
$sts = Get-SPSecurityTokenServiceConfig
$sts.UseSessionCookies = $false
$sts.Update()
If UseSessionCookies is true, you will have to login to any docs u want to download...
I have an issue with SharePoint search.
The situation
The server is installed with
SharePoint on a farm with 2 servers.
A new app pool is created and that app pool is using a domain account called moss_service.
moss_service is set to be in the administrator group in both server.
moss_service is also set to be the db_creator in the content database.
When I checked it initially, the search's default content access account is using another different account, I changed that to be using moss_service account.
I didn't do IIS reset because this is a production server, they dont want frequent iis reset.
Strangely, checking the services.msc under "office sharepoint server search" the account is still using an old one. (and apparently it's only running on 1 server, the other server is not running) I then change that to the following:
domain\moss_service with the password.
and then I rerun the crawl.
How do I diagnose the issue
Basically everytime I change something I restart the crawl and then check the event viewer. Multiple things come out but the following is the major ones:
The start address cannot be
crawled. The password for the content
access account cannot be decrypted
because it was stored with different
credentials. Re-type the password for
the account used to crawl this
content. (0x80042406)
Performance monitoring cannot be
initialized for the gatherer object,
because the counters are not loaded or
the shared memory object cannot be
opened. This only affects availability
of the perfmon counters. Restart the
computer.
Access is denied. Check that the
Default Content Access Account has
access to this content, or add a crawl
rule to crawl this content.
(0x80041205)
Crawl Logs Result
The crawl log is showing this:
The password for the content access account cannot be decrypted because it was stored with different credentials. Re-type the password for the account used to crawl this content.
I tried changing it again at service.mstsc and the rerun the full crawl again but then it doesn't work. I have tried entering it using the following way:
moss_service#domain.local
and
domain\moss_service
My Questions are:
How do I fix this?
Is this the right way to setup the
search?
Does the search account has to be
using a different domain account?
Seemed like one fix complicates the
other, how do I set this right?
Is it worth it to upgrade to sp2?
Google this you will get answer " Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. "
Alex, I think you need to completely reconfigure the search services. Keep in mind that the search crawler should be an account with least privileges (not your application service account!). Also, the indexer only runs on one server and whether the search crawler runs on one or more machines is another configuration issue. Also, some settings changes (like changing the crawled File Types) even require the search engine to be restarted.
The start address cannot be crawled. The password for the content
access account cannot be decrypted because it was stored with
different credentials. Re-type the password for the account used to
crawl this content.
For this error,
Open the Sharepoint administration
Click on "Application Management"
Click on "Manage service applications"
Click on "Search Service Application"
Click on the current value for "Default content access account" and re-enter the user's password, or update to another admin user.
We have a SharePoint application where we want the user to be able to modify the web.config by activating a feature. The application is extended, so we have an AD based web application and another that uses Forms Based authentication (FBA), with the FBA application being the "main" user application.
We use the SPWebConfigModification class (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebconfigmodification.aspx) to write to the web.config for settings we need for the activated feature.
This works great on the AD based side of things. However, when we try and run this on the FBA based web app, we get an error because the site collection administrator for the FBA site, does not have any access to modify the web.config on the server. Given that they are a FBA user, we can not give them rights on the server either.
Has anyone run into this? Does anyone have any work arounds. I assume I could try and have the application to update the web.conifg run via the command line, but I would really like it be done by the user when they activate the feature. I could also try and loosen security rights on the web.config, but that is a bad path to start down.
Thanks!
John
An alternative would be to write a component which does it.
This could be trigged by activating a feature, or updating a webpart.
This would mean you don't need to loosen security, or do it via the command line.