J'utilise un service WCF pour exposer certaines fonctions de gestion Active Directory à notre service d'assistance sans leur donner l'appartenance au groupe nécessaire pour manipuler directement AD. Ajout d'utilisateurs et suppression d'utilisateurs des groupes travaille comme un champion avec les utilisateurs existants, mais chaque fois que je crée un nouvel utilisateur, il rejette ce code amusant:L'ajout d'un utilisateur au groupe de sécurité AD échoue après la création de l'utilisateur
The server is unwilling to process the request. (Exception from HRESULT: 0x80072035)
Le code que j'utilise pour ajouter l'utilisateur au groupe est
public bool AddGroupToUser(string userDn, string groupDn)
{
try
{
DirectoryEntry groupEntry = LdapTools.GetDirectoryEntry(groupDn);
groupEntry.Properties["member"].Add(userDn);
groupEntry.CommitChanges();
groupEntry.Close();
return true;
}
catch (DirectoryServicesCOMException)
{
return false;
}
}
Tout ce que j'ai lu sur le sujet est assez vague et je ne peux pas sembler trouver pourquoi l'exception est déclenchée. Des idées?
MISE À JOUR
Voici le code que j'utilise pour créer l'utilisateur dans AD:
try
{
DirectoryEntry container = GetDirectoryEntry(storageOu);
DirectoryEntry newUser = container.Children.Add("CN=" + employee.FullName, "user");
newUser.Properties["sAMAccountName"].Value = employee.Username;
newUser.Properties["displayName"].Value = employee.FullName;
newUser.Properties["givenName"].Value = employee.FirstName;
newUser.Properties["sn"].Value = employee.LastName;
newUser.Properties["department"].Value = departmentName;
newUser.Properties["userPrincipalName"].Value = employee.Username + "@APEX.Local";
newUser.CommitChanges();
newUser.Invoke("SetPassword", new object[] { employee.Password });
newUser.CommitChanges();
AdsUserFlags userSettings = AdsUserFlags.NormalAccount;
newUser.Properties["userAccountControl"].Value = userSettings;
newUser.CommitChanges();
ldapPath = newUser.Path;
newUser.Close();
container.Close();
}
catch (DirectoryServicesCOMException e)
{
// Something went wrong... what???
}
catch (Exception e)
{
// Something else went wrong
}
Le nouvel utilisateur peut se connecter, et peut être manipulé à l'aide des outils standard MS.
Je ne pense pas que les primitives DirectoryEntry sont garanties d'utiliser la même liaison AD en interne, il est donc tout à fait possible de manipuler le groupe sur un contrôleur de domaine différent de celui auquel vous avez ajouté l'utilisateur (AD utilise un modèle de réplication multimaître). Le temps nécessaire à la réplication pour terminer dépend du nombre de contrôleurs de domaine, le paramètre qui détermine le délai d'attente avant de notifier les homologues d'un changement et le volume des transactions AD. Dans un grand domaine, j'ai vu AD prendre plus de 5 minutes pour répliquer pleinement un SPN, alors faites attention avec 8 secondes. –
J'ai écrit un wrapper autour de DirectoryEntry visant à résoudre le problème de ne pas savoir à quel contrôleur de domaine je me connecte. Je me connecte au même DC chaque fois maintenant et il ne reconnaît toujours pas le DirectoryEntry sur les appels suivants avant que la période de 8 secondes ne soit passée. Heureusement, pour l'instant au moins, je n'ai qu'à m'inquiéter de deux DC. Le ciel m'aide si nous commençons à ajouter un DC par emplacement. Savez-vous d'un moyen de savoir quand le SPN a été entièrement répliqué? – thaBadDawg