I'm writing a VBscript that I would like to alter the anyonymous authentication configuration for a specific site on my web server. However, I'm unsure of how this is done in the commit path. Currently, I am able to change the setting on a global scale, but I only want to target one particular site folder. My best guess was to simply include the site path at the end of MACHINE/WEBROOT/APPHOST.
'CHANGE ANONYMOUS AUTHENTICATION GLOBALLY (working code):
Set adminManager = CreateObject("Microsoft.ApplicationHost.WritableAdminManager")
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST")
anonymousAuthenticationSection.Properties.Item("enabled").Value = True
anonymousAuthenticationSection.Properties.Item("userName").Value = "myUser"
anonymousAuthenticationSection.Properties.Item("password").Value = "myPass"
adminManager.CommitChanges()
'MY BEST GUESS AT TARGETING A SPECIFIC SITE (returns error 80070005):
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST/Sites/InsideFTL/Corp/redirects/netXposure")
The code that you have above should work, are you running it from an elevated command prompt?
You could also try to make sure that it is committing to ApplicationHost.config to make sure it is not a locking issue by setting CommitPath, and make sure that the identity under you are running the script has write access to it.
'CHANGE ANONYMOUS AUTHENTICATION For Default Web Site:
Set adminManager = CreateObject("Microsoft.ApplicationHost.WritableAdminManager")
adminManager.CommitPath = "MACHINE/WEBROOT/APPHOST"
Set anonymousAuthenticationSection = adminManager.GetAdminSection("system.webServer/security/authentication/anonymousAuthentication", "MACHINE/WEBROOT/APPHOST/Default Web Site")
anonymousAuthenticationSection.Properties.Item("enabled").Value = True
anonymousAuthenticationSection.Properties.Item("userName").Value = "myUser"
anonymousAuthenticationSection.Properties.Item("password").Value = "myPass"
adminManager.CommitChanges()
Related
I have an application developed in vb.net which needs administrator privileges. I have set level = "requireAdministrator" in the application manifest. My client wants this application to be run by a local user due to some restrictions in their organization. So I created another ‘Launcher’ application which will actually save an administrator credentials in an encrypted format and will use the saved credentials to run the ‘Original’ application.
Everything works fine if I’m using the ‘Administrator’ account (Built-in account). But if I’m using the credentials of the manually created administrator account – the process.start () line is throwing an error “The requested operation requires elevation”
I really couldn’t identify the difference between the built-in administrator and manually created administrator account. I confirmed that both the users (built-in and manually created) are members of Administrators and HomeUsers. I tried all possibilities by creating different users with different user groups and even with different OS (windows 7 and Windows 10 – both 32 and 64 bit versions) – but, all are working in the same manner as explained above. Is there anything that I have to change in my code?
Dim psi As New System.Diagnostics.ProcessStartInfo()
psi.FileName = (AppToStart)
psi.RedirectStandardError = True
psi.RedirectStandardOutput = True
psi.CreateNoWindow = True
psi.UseShellExecute = False
psi.UserName = TbUser.Text
psi.Password = ConvertToSecureString(TbPass.Text)
psi.Domain = ""
Dim p As Process = Process.Start(psi)
Additional Info: Here I'm running this 'Launcher' application as a standard user (not administrator) and the application works well and it really elevates the privileges if
TbUser.Text = “Administrator” and
TbPass.Text = 123 (Administrator password).
But this is not elevating privileges if
TbUser.Text = “Adminuser” (which is also an administrator belongs to the same ‘Administrators’ group) and
TbPass.Text = 321 (password for Adminuser).
Unfortunately you can't do this and here is why...
Basically verb isn't recognized when psi.UseShellExecute = False, this would need to be psi.UseShellExecute = True. You are doing this while trying to use runas as an elevated permission.
In your situation, you would not use the verb = runas, make sure the application has already been started with the correct permissions.
Please see more here about elevating privileges, Hans Passant say's it best...
I created my vb.net project to .exe file.
During installation on another machine, one can change the location of installing package to any drive.
In my project, I have set my app.config to point the Database that is available in c:\project.
If I suppose, while installation, when I change the location of installation to **d:** or anywhere, I get invalid access db.
What I want is:
I want to reconfigure my app.config file automatically, by detecting its current db location.
Imports System.Configuration
Imports System.Configuration.ConfigurationManager
Dim config As System.Configuration.Configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
config.ConnectionStrings.ConnectionStrings("MyProject.Properties.Settings.MyProjectConString").ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;DataSource=|DataDirectory|\SampleDB;Persist Security Info=True;"
config.Save(ConfigurationSaveMode.Modified)
Where MyProject.Properties.Settings.MyProjectConString is the name of your project and connection string.
Although this is too late to answer as the question is very old but I think this might help someone else in the future.
So, there is a way to change the Connection String value in the runtime. Since connection string is a read-only item like all other items that are on Application Scope under My.Settings so we can't change it using My.Setting.ConnectionString = "Something". But here is the code by which you can solve the issue and change any My.Settings item that is on Application Scope in the runtime.
So the code is,
My.Settings.Item("ConnectionString") = "Something"
simple...
MsgBox(My.Settings.Item("remoteAddress").ToString)
My.Settings.Item("remoteAddress") = "abcserver.servebbs.net"
My.Settings.Save()
MsgBox(My.Settings.Item("remoteAddress").ToString)
You have three options:
1.) Create and use a folder in C:\Databse and set your connection string at design time.
2.)Add the database to the project's data source at design time, then use '|Data Directory|\mydb.mdb' as your connection string.
3.) And if you use sqlserver, you don't need to worry about the location of the database once you have attached the database to sqlserver. You only need to use the proper connection string eg 'Data Source=.; Database = mydb; Integrated Security = False; Username=myusername; Password = mypassword; User Instance = false'.
The above is an example of a sql server with SQL Authentication mode as login, if you use Windows Authentication, set Integrated Security = True and remove both username and password.
I have just moved a site from a dedicated server to a GoDaddy shared hosting account, and have just encountered loads of problems! One being with ASP Upload.
In Classic ASP, this is what I would normally do to upload files to my folder:
Set upload = Server.CreateObject("Persits.Upload")
uploadPath = Server.MapPath("../../files/photos/"&token_&"/")
upload.IgnoreNoPost = True
upload.Save(uploadPath)
Set upload = Nothing
But since moving to GoDaddy, I get this nasty message:
This feature has been disabled by the system administrator. Use SaveVirtual instead.
I went on to ASP Upload's website documentation and I could not find SaveVirtual, only SaveAsVirtual which is where I have become unstuck.
I tried using SaveAsVirtual but it threw an error stating that I was using a physical path and I should be using a virtual path! I really don't understand this and was hoping that somebody could put me straight. My website is now deemed broken and is offline, please help.
This is what I tried before the physical/virtual path error:
Set upload = Server.CreateObject("Persits.Upload")
uploadPath = Server.MapPath("../../files/photos/"&token_&"/")
upload.IgnoreNoPost = True
upload.SaveAsVirtual(uploadPath)
Set upload = Nothing
According to the docs, the method is named SaveVirtual. It does the Server.MapPath conversion for you.
So, try:
Set upload = Server.CreateObject("Persits.Upload")
uploadPath = "../../files/photos/"&token_&"/"
upload.IgnoreNoPost = True
upload.SaveVirtual(uploadPath)
Set upload = Nothing
You already set a folder path to upload not need use like this "server.mappath"
please use below of code.
Set Upload = Server.CreateObject("Persits.Upload" )
Upload.SetMaxSize 10000000 ' Maksimum dosya büyüklüğü Byte cinsinden
Upload.OverwriteFiles = True
Path = "../../duyurular/"
Count = Upload.SaveAsVirtual(Path)
for godaddy you have to go in and change the server folder permission to read/write. Otherwise you get that error message.
well I also get encounter with this problem, I just changed the folder privileges from Go-daddy Hosting server so Any one can read or Write file from specific location
Many Thanks
Ahsan Aziz Abbasi
I have an active Trac installation with multiple projects. I am using the AccountManagerPlugin to manage user accounts, and to allow users to manage their own accounts.
My current AccountManagerPlugin configuration looks like this:
[account-manager]
account_changes_notify_addresses =
authentication_url =
force_passwd_change = true
generated_password_length = 8
hash_method = HtDigestHashMethod
htdigest_realm = TracRealm
notify_actions = []
password_file = /home/sms/trac_sites/trac.htdigest
password_store = HtDigestStore
persistent_sessions = true
user_lock_max_time = 0
verify_email = false
This works great, except: Each Trac project currently requires separate authentication. The projects are unable to share their authentication cookies.
Setting auth_cookie_path = /trac does not work, because session data is stored in each project's own database; therefore one project cannot validate the cookie of another. Worse, this causes projects to overwrite each other's cookies.
Using an undocumented two-year-old monkey patch (SharedCookieAuthPlugin) seems like a bad idea.
Is there a solution?
SharedCookieAuthPlugin is indeed the way to go. The author of the plugin (k0s, alias Jeff Hammel) was the person who requested the auth_cookie_path option, specifically for his plugin. The fact that it hasn't been updated in two years just means that it works as it is.
I'm trying to write an application that will allow a non-administrator user to create virtual directories in IIS6. I've tried numerous different ways of impersonating a administrative account but nothing seems to work to create the virtual directory.
Here's some of what I've tried:
dim sDirPath as string = "IIS://remotehost/W3svc/1/root"
Dim de As DirectoryEntry = New DirectoryEntry()
de.Path = sDirPath
de.AuthenticationType = AuthenticationTypes.Secure
de.Username = tbxUsername.Text
de.Password = tbxPassword.Text
''Fails here
virtualId = CType(de.Invoke("Create", "IIsWebVirtualDir", dirName), DirectoryEntry)
Using the AccountAlias class from here:
aa.BeginImpersonation()
Try
dim sDirPath as string = "IIS://remotehost/W3svc/1/root"
Dim de As DirectoryEntry = New DirectoryEntry()
de.Path = sDirPath
de.AuthenticationType = AuthenticationTypes.Secure
''Fails Here
virtualId = CType(de.Invoke("Create", "IIsWebVirtualDir", dirName), DirectoryEntry)
Finally
aa.EndImpersonation()
End Try
what is the correct way to impersonate another user in winforms application that will allow me to create the virtual directory WITHOUT the user that's running the application being an administrator on the web server? I know this can be done, IIS manager allows you to use "connect as" checkbox to do it.
It's been a long time since I hit this problem so I may be remembering a few things wrong. But IIRC ...
The root directory of IIS is protected by an ACL that requires administrative privs in order to create a new directory. A simple impersonation likely will not fix this issue because I believe under the hood you are combining both COM and either RPC or Local RPC. Impersonation across COM boundaries is tricky in native code and very tricky from managed code. It's very likley that you are running into an issue in this area with your impersonation trick.
It is possible though to lift the restriction on the web server and have normal users create root directories in IIS. I outlined the process to do so in the following blog post
http://blogs.msdn.com/jaredpar/archive/2005/02/04/367137.aspx