Develop Reference

AD UserPrincipal ChangePassword method creates user profile folders in C:\Users

We have a .NET Framework application used for changing user passwords. It uses the System.DirectoryServices.AccountManagement assembly.
Process goes as follows:
A user fills out a simple form (username, old pw, new pw, new pw repeated).
UserPrincipal.FindByIdentity() gets called to find the user
UserPrincipal.ChangePassword() gets called to change the password
Note: Principal context type is set to DOMAIN
Note2: everything works, the issue is with the user folders.
So apparently ChangePassword() creates a user profile in C:\Users folder in the application's machine and I cannot find any information why that happens. I would understand in the context was set to Machine, but in this case it's not.
There are over 6k folders now, one for each user, it's taking up a lot of space and slowing the machine down.
I tried recreating the problem locally and apparently the ChangePassword() creates a TEMP user profile in C:\Users in my computer, but then it disappears.
Code
Configuration
container.RegisterType<PasswordChangeService>(new InjectionFactory(m => new PasswordChangeService(
new PrincipalContext(ContextType.Domain, ConfigurationManager.AppSettings["LdapDomain"], ConfigurationManager.AppSettings["LdapQuery"]),
new LogService(new Persistence.LogDbContext())
)));
Code for finding user, changing password
using (var user = UserPrincipal.FindByIdentity(_principalContext, IdentityType.SamAccountName, passwordChange.Username)) {
if (user == null) {
Fail(passwordChange, "User not found");
}
user.ChangePassword(passwordChange.CurrentPassword, passwordChange.NewPassword);
LogSuccess(passwordChange);
}
Can anyone tell me why the user profiles get created?
How to fix this issue? Is this a configuration or permission problem?
(optional) I've seen examples where UserPrincipal.Save() gets called after, say, ChangePassword(), but it has always worked without it, so in what situation can it be used?
Thank you.
Update
after some unsuccessful searching I found out a few things that might be worth mentioning:
1. Someone from 2009 had the same problem technet link
The last comment "Since all the code snippets utilize the ChangePasword implementation of ADSI (which causes the profile generation) the simplest way to accomplish this programmatically would be to not use ADSI but System.DirectoryServices.Protocols instead and perform an attribute modification against unicodePwd".
2. When calling ChangePassword(), user directory was sometimes not created and at at those times Event Viewer showed a couple of errors
"Windows has backed up this user profile. Windows will automatically try to use the backup profile the next time this user logs on."
"Windows cannot find the local profile and is logging you on with a temporary profile. Changes you make to this profile will be lost when you log off."
3. Every "fix" I've seen resulted in fixing the consequence, but not the cause. I still have no idea why the profiles get created, but if the technet comment is legit, I guess I need to use another implementation.
I ended up using an example from SO link and this is my result:
string ldapPath = ConfigurationManager.AppSettings["LdapPath"];
string domainWithUserName = string.Format(ConfigurationManager.AppSettings["LdapDomain"], "\\", passwordChange.Username);
DirectoryEntry directoryEntry = new DirectoryEntry(ldapPath, domainWithUserName, passwordChange.CurrentPassword);
if (directoryEntry != null) {
DirectorySearcher search = new DirectorySearcher(directoryEntry);
search.Filter = "(SAMAccountName=" + passwordChange.Username + ")";
SearchResult result = search.FindOne();
if (result != null) {
DirectoryEntry userEntry = result.GetDirectoryEntry();
if (userEntry == null) {
Fail(passwordChange, "User not found.");
}
userEntry.Invoke("ChangePassword", new object[] { passwordChange.CurrentPassword, passwordChange.NewPassword});
userEntry.CommitChanges();
LogSuccess(passwordChange);
}
}
I still need to narrow down the AD search to a specific OU, etc.
This implementation works, no user profile gets created, Event Viewer shows nothing. It's a shame, really, because I'd rather call a few methods instead of using 15 lines of code that do the same thing.

How to check whether access permissions have changed for a directory in C#?

Following is the code that I have written,
var prevSecInfo = Directory.GetAccessControl(path);
if (Utilities.ShowChangePermissionsWindow(path)) {
var currSecInfo = Directory.GetAccessControl(path);
if (currSecInfo != prevSecInfo)
Utilities.ApplyPermissionsOnSubdirectories(path);
}
So, currently, I am getting the access control info before displaying the permissions window.
Next, I am displaying the permissions window which is actually the Security tab of the file/folder properties window. Changes can be made in permissions once it opens up.
But, in case no changes are made, I don't want to call my ApplyPermissionsOnSubdirectories() method. Hence, I am getting the access control info again in another variable and comparing the previous and the current info.
But, this isn't working. The comparison returns false even when no permissions are changed.
How can I check whether permissions have changed for the given path?

You cannot compare the contents of two reference type objects this way.
if (currSecInfo != prevSecInfo) will always return false, unless they both reference to the same object.
Unfortunately, DirectorySecurity type also does not provide Equals overriden method.
There is a StackOverflow article with some ready-made solutions for comparing permissions:
compare windows file (or folder) permissions

While working on the problem above, I found another solution which looks less complex and shorter is terms of code.
DirectorySecurity securityInfoBefore = Directory.GetAccessControl(path, AccessControlSections.Access);
string aclStrBefore = securityInfoBefore.GetSecurityDescriptorSddlForm(AccessControlSections.Access).ToString();
Here, path is the absolute path to the file/folder.
The aim to get the DirectorySecurity object before the permissions are changed and getting the SecurityDescriptorSddlForm as a string.
Now you can add your code to change the permissions. After the permissions are changed, add the following code,
DirectorySecurity securityInfoAfter = Directory.GetAccessControl(path, AccessControlSections.Access);
string aclStrAfter = securityInfoAfter.GetSecurityDescriptorSddlForm(AccessControlSections.Access).ToString();
The next step would be to compare the before and after strings.
if (aclStrBefore.Equals(aclStrAfter)) {
// permissions have not changed
} else {
// permissions have changed
}
This has helped me so far. Please feel free to add to my answer or correct it if required.

Event Creation is not working

I have source "Source401" used for log "Log401". I need to use this source for "Log402" log and delete the log "Log401". (If we can rename “Log401” as “Log402” that is also fine. But all this need to be done programmatically)
With the code below, I am getting the following exception. What is the best way to achieve it?
Source Source401 already exists on the local computer.
Note: When I delete the old log, it is working fine. But the events are not getting created.
UPDATE
From MSDN
The operating system stores event logs as files. When you use EventLogInstaller or CreateEventSource to create a new event log, the associated file is stored in the %SystemRoot%\System32\Config directory on the specified computer. The file name is set by appending the first 8 characters of the Log property with the ".evt" file name extension.
The source must be unique on the local computer; a new source name cannot match an existing source name or an existing event log name. Each source can write to only one event log at a time; however, your application can use multiple sources to write to multiple event logs.
CODE
string source = "Source401";
string logName = "Log402";
string oldLogName = "Log401";
string eventName = "Sample Event";
string machineName = ".";
if (!EventLog.Exists(logName, machineName))
{
////Delete old log
//if (EventLog.Exists(oldLogName, machineName))
//{
// EventLog.Delete(oldLogName, machineName);
//}
//Create Source for the Log
EventLog.CreateEventSource(source, logName, machineName);
//Create Event
EventLog eventLog = new EventLog(logName, machineName, source);
eventLog.WriteEntry(eventName);
try
{
eventLog.WriteEntry(eventName, EventLogEntryType.Warning, 234, (short)3);
}
catch (Exception exception)
{
int x = 0;
}

The exception is telling you exactly what the problem is. The event source named "Source401" already exists. You're deleting the old event log, "Log401", but you're not deleting the event source.
As the documentation says:
The operating system stores event logs as files. When you use EventLogInstaller or CreateEventSource to create a new event log, the associated file is stored in the %SystemRoot%\System32\Config directory on the specified computer. The file name is set by appending the first 8 characters of the Log property with the ".evt" file name extension.
The source must be unique on the local computer; a new source name cannot match an existing source name or an existing event log name. Each source can write to only one event log at a time;
Also, this little nugget:
If a source has already been mapped to a log and you remap it to a new log, you must restart the computer for the changes to take effect.
In addition, you might want to consider this, also from the documentation:
Create the new event source during the installation of your application. This allows time for the operating system to refresh its list of registered event sources and their configuration. If the operating system has not refreshed its list of event sources, and you attempt to write an event with the new source, the write operation will fail
Finally, the CreateEventSource method you're calling is marked obsolete, and has been since .NET 2.0. There's usually a good reason for methods to be marked obsolete. You should be calling CreateEventSource(EventSourceCreationData).
I think you need to re-think the way you're using event logs. Your application shouldn't be creating and deleting logs that way. It's not how they're intended to be used.

Modifying an existing access control entry

I had made a logic error in the FileSystemRights interpretation which was causing it to always applied Read permission no matter what else was entered.
I'm making a ps cmdlet which is meant to be fed a list of username and modify the permissions for a folder of the same name as the user. From my testing this script will create the new special acl entry for the user for an allow or deny entry however it will not modify the entry if it already exists. I.e. if a user has read access already and I attempt to grant write access it does not change the entry. I am not sure how I would go about modifying the existing permission without completely removing the old permissions.
DirectoryInfo diDirInfo = new DirectoryInfo(FolderName);
DirectorySecurity dsDirSecurity = diDirInfo.GetAccessControl();
//These just interpet the objects for the rights and the allow/deny entries from the command line
FileSystemRights FSR = genFSR();
AccessControlType ACT = genAct();
dsDirSecurity.AddAccessRule(new FileSystemAccessRule(UserName, FSR, ACT));
diDirInfo.SetAccessControl(dsDirSecurity);
I tried ModifyAccessRule and got the same behavior.
FileSystemAccessRule fsaRule = new FileSystemAccessRule(UserName, FSR, ACT);
dsDirSecurity.ModifyAccessRule(AccessControlModification.Add, fsaRule, out modified);

Use ModifyAccessRule instead of AddAccessRule.
See http://msdn.microsoft.com/en-us/library/system.security.accesscontrol.objectsecurity.modifyaccessrule.aspx

Sharepoint 2007 - is there a way to determine if first check-in of file?

I thought this would be a lot easier, however I'm unable to find a way to determine in my event handler if it is the FIRST check-in of the file..
You see, I'm breaking role inheritance, and selectively inheriting permissions for files in doc libs, yet I wish to do it only once, during the first check-in of the file.
I've tried adding an entry to 'SPListItem.Properties' in the ItemAdded event in order to indicate if the file is new, however the moment I do 'SPListItem.Update()' it vanishes..
I've played with the ItemCheckingIn and ItemCheckedIn events with no success...
My only hope at the moment is adding a SPField to the ContentType to indicate if new file or not, but I really wish to avoid it..
ANY IDEAS????
PLEASE HELP ME!

I would recommend considering not only whether the system account has access, but also if the checked out date of the file is identical to the file's creation date.
public bool IsFirstCheckIn(SPListItem item)
{
// Item not null!
if (item != null)
{
SPSecurity.RunWithElevatedPrivileges(delegate
{
// Open privileged Site
using (SPSite pSite = new SPSite(site.ID))
{
// Open privileged Web
using (SPWeb pWeb = pSite.OpenWeb(web.ID))
{
// Create privileged SharePoint-Objects
SPList pList = GetList(pWeb, list.ID);
SPListItem pItem = GetListItem(pList, item.UniqueId);
// Check the Item
if (pItem == null)
{
// Can't access
return true;
}
else if (pItem.File != null && pItem.File.CheckedOutByUser != null)
{
// If the Item's File and checked out User is set, check if checked out date is equal creation date
return (pItem.File.CheckedOutDate.ToLocalTime() == pItem.File.TimeCreated.ToLocalTime());
}
}
}
});
}
return false;
}
To use the system account, is definitely a good idea, otherwise authorization settings would cause problems. Use the "local time" instead of the "UTC-Time", SharePoint handled the Time Zone while storing!
Seems like, SharePoint used the UTF-FileTime to store the file's creation time but used the Time Zone defined for the SPWeb or for the SPUser to store the file checked out date based on the "local time".
Fortunately the DateTime value does know what it is and can convert it to the same "local time" while calling ToLocalTime(). Strangely it will be still a File-Time while calling ToUniversalTime();

So I got a solution for this.
I'm sorry I can't post code here, I do not have access to internet on my dev machine.
It should be good enough for everyone.
Solution:
During the CheckingIn event I try to access the file using the SHAREPOINT\system("SPSecurity.RunWithElevatedPrivileges()"). During the first check-in the file is new and not accessible to other users besides the uploader.
So if I fail getting the file with SHAREPOINT\system it means its new, and I save its Guid in a dictionary in my EventHandlers class.
Then in the CheckedIn event I simply check if the dictionary contains the Guid of the current item, if it does - FIRST CHECK-IN, if it does not - NOT FIRST CHECK-IN.
Of course after I'm finished with the file I remove the entry from the dictionary.
Hope it helps, if you got any questions you are welcome to ask :)