Disconnect the Microsoft account from your local user account programmatically via registry or COM? - windows-8

Since Windows 8 (?) the default way of setting up a new a user account is to attach a Microsoft account to the local account.
I'd like to programmatically disconnect that Microsoft account from the local user account, (without losing settings/data) to end up with a traditional clean local account.
I don't have access to WinAPI functions or DLLs, but I can use the COM API access the registry.
So I'm basically just looking for a list of registry entries that I would have to remove or maybe a COM object method that allows me to do it.
Any idea how I could accomplish that?
The programming language I'll be using for that isn't relevant, but since you will ask for it anyway... it's JScript.

Related

Find Client PC name behind Remote Desktop connection

This is a bit general question.
I have a Windows application writted on VB (or whatever language) that has a login system. This app use computers registry to save and retrieve last login used, so the next time the user run the application it only needs to type his password. This works just fine.
Now one client wants to install my app in his server instead of clients computers and make all the pcs access the system via Remote desktop. No problem here.
My problem comes with the login system, because if i use the registry to save last login user, it will be only one (the server registry) so I always get last login user independet of wich pc access the system.
So my question is: How can I set a default user for each client PCs? I could use my database instead of the registry to save an retrieve last login user, but for then I'll need to know the PC name behind the remote desktop, and I don't know if thats even possible... Any ideas?
Thanks!
Note regardless duplicated post:
My question is different from the above mention. I don't need to get user name from terminal server. I just need a way to save and retrieve some data on the registry for each terminal service user or client PC.

IIS 6.0 on Windows Server 2003 setup for Integrated Windows Authentication but no direct access for users to the shared folders

I am attempting to set up an IIS 6.0 application running on Windows Server 2003 to use impersonation in order to avoid having to give users direct read/write access to the shared folders where the DB and web pages are stored. Can anyone provide me with details of how this can be set up to work in conjunction with Windows Integrated Authentication?
So far, I can tell that the web.config file (not sure whether it's the correct one) has the two lines mentioned on this thread (Impersonation in IIS 7.0) to allow impersonation and use the Windows logon method. However, users are still prompted for a logon and then told they are not authorized to view web pages. They can view pages if we turn anonymous logon "on", but then their user credentials aren't passed on to the site and therefore they can't access most of it.
I'm fairly inexperienced, so I'm a bit lost here. Thank you very much in advance for the help!
Thanks to intervention from Microsoft (definitely worth the flat fee they charge per incident), we were able to identify the problem. Instead of using the network path to identify the website location on the "Home Directory" tab of the IIS properties, we were using the local drive path. That was all that needed to be changed.
Once we switched to the network path and added a dedicated service account to "Connect As...", impersonation started working right away. Users pass their logged on credentials via integrated authentication (no logon required) and the service account takes care of executing their actions on the database file.
Access to the shared folder is limited to a brief list of administrators, and data access on the web application is limited based on user names.
If anyone is stuck with this and needs help, let me know!

Granular access control for MediaWiki with LDAP

My company has a MediaWiki setup which we are looking to make [partially] client accessible. Ideally each client would be able to see only their own page. Our wiki requires the user to be logged into view or edit, and we have the LDAP plugin (This one, specifically) so we can use our Active Directory credentials.
I see this question has come up before a few years ago, but I didn't see an question dealing with LDAP in particular. Can we manage a specific AD account if we give clients one on our domain for this purpose? Alternatively, is there a way to give clients a login directly into the wiki (sort of like logging locally into the computer, instead of the domain), that we could control the access rights of?
For reference: we are on MediaWiki version 1.19.1, PHP version 5.3.15, MySQL version 5.0.96-winx64, and the installation is running on Windows Server 2008 R2 x64 (IIS 7.5).
Thanks very much for the help!
You can use local accounts in addition to the LDAP accounts to log users in. You have to set $wgLDAPUseLocal to true in your LocalSettings.php. Basically, it adds another option to the domain drop down box on the login form that says "local". Users that want to log in with a local wiki account use that. I would also disable account creation on the wiki and create accounts manually for your clients.
Regardless of whether you use local accounts or AD accounts, for page-level access control, you would have to use one of these extensions. Extension:AccessControl seems to be a popular one.

Allow a TFS 210 User to Change Their Password

We work with a group of contractors that need access to our TFS 2010 server. I've got Active Directory running for our office, so every user has an AD account. Is there a way the TFS users can change their passwords through TFS? I've changed passwords before by having users RDP into computers and changing their account information there, but I'd rather not give the contractors RDP access (they just don't need it).
I tried selecting "user mush change password at next login", but TFS seems not to respond to that.
The only login vehicle the contractors use is TFS.
Thanks
That's correct, TFS doesn't provide a mechanism to change passwords. Your users will need to use some integration to Active Directory to change their password. It needn't necessarily be through an RDP session, as long as they can hit Active Directory's LDAP server, you should be able to allow this.
IIS ships with a tool called IISADMPWD that lets users change their password over the web.
In addition, you can build your own tool to change the password, like other people have done in PowerShell or perl. In addition, there appear to be various commercial tools to enable this.

Understanding IIS6 permissions, ACL, and identity--how can I restrict access?

When an ASP.NET application is running under IIS6.0 in Windows 2003 Server with impersonation, what user account is relevant for deciding file read/write/execute access privileges? I have two scenarios where I am trying to understand what access to grant/revoke. I thought the most relevant user is probably the identity specified in the Application Pool, but that doesn't seem to be the whole story.
The first issue concerns executing a local batch file via System.Diagnostics.Process.Start()--I can't do so when the AppPool is set to IWAM_WIN2K3WEB user, but it works fine if it is set to the Network Service identity. I of course made sure that the IWAM user has execute rights on the file.
The second involves writing to a file on the local hard drive--I'd like to be able to prevent doing so via the access control list via folder properties, but even when I set up all users in the folder as "read" (no users/groups with "write" at all), our ASP.NET still writes out the file no problem. How can it if it doesn't have write access?
Google search turns up bits and pieces but never the whole story.
what user account is relevant for [..] file read/write/execute access
As a rule: Always the user account the application/page runs under.
The IWAM account is pretty limited. I don't think it has permissions to start an external process. File access rights are irrelevant at this point.
If a user account (Network Service in your case) owns a file (i.e. has created it), it can do anything to this file, even if not explicitly allowed. Check who owns your file.
Process Monitor from Microsoft is a great tool to track down subtleties like this one.
A bit more searching reveals that the IWAM user isn't that well documented and we should stick with NETWORK SERVICE or a manually-supplied identity if we want to specify permissions for that user.