Erro 0x80005000 e serviços de Direcção
estou a tentar executar uma simples pesquisa LDAP usando os Serviços de directórios em. Net.
DirectoryEntry directoryEntry = new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com");
directoryEntry.AuthenticationType = AuthenticationTypes.Secure;
DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry);
directorySearcher.Filter = string.Format("(&(objectClass=user)(objectCategory=user) (sAMAccountName={0}))", username);
var result = directorySearcher.FindOne();
var resultDirectoryEntry = result.GetDirectoryEntry();
return resultDirectoryEntry.Properties["msRTCSIP-PrimaryUserAddress"].Value.ToString();
e estou a ter a seguinte excepção:
System.Runtime.InteropServices.COMException (0x80005000): Unknown error (0x80005000)
at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
at System.DirectoryServices.DirectoryEntry.Bind()
at System.DirectoryServices.DirectoryEntry.get_AdsObject()
at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne)
at System.DirectoryServices.DirectorySearcher.FindOne()
13 answers
Quando você executa o aplicativo da consola, esse aplicativo funciona com suas credenciais, por exemplo, como "você".
O serviço WCF funciona onde? Em IIS? O mais provável é que ele seja executado sob uma conta separada, que não é permissioned para consultar Diretório Ativo.Você pode tentar fazer com que a imitação da WCF funcione, para que as suas próprias credenciais sejam passadas, ou pode especificar um nome de utilizador / senha ao criar a sua Director:
DirectoryEntry directoryEntry =
new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com",
userName, password);
OK, então pode não ser as credenciais afinal (que é geralmente o caso em mais de 80% dos casos que eu vejo).
E se mudasses um pouco o teu código?DirectorySearcher directorySearcher = new DirectorySearcher(directoryEntry);
directorySearcher.Filter = string.Format("(&(objectClass=user)(objectCategory=user) (sAMAccountName={0}))", username);
directorySearcher.PropertiesToLoad.Add("msRTCSIP-PrimaryUserAddress");
var result = directorySearcher.FindOne();
if(result != null)
{
if(result.Properties["msRTCSIP-PrimaryUserAddress"] != null)
{
var resultValue = result.Properties["msRTCSIP-PrimaryUserAddress"][0];
}
}
A minha ideia é: porque não dizer logo ao {[[2]} em que atributo está interessado? Então você não precisa fazer mais um passo extra para obter o DirectoryEntry completo do resultado da pesquisa (deve ser mais rápido), e uma vez que você disse ao pesquisador de diretório para encontrar essa propriedade, é certamente vai ser carregado no resultado da pesquisa - então, a menos que seja nulo (nenhum conjunto de valores), então você deve ser capaz de recuperá-lo facilmente.
Marc
ldap:// para LDAP:// fez o truque.
No contexto do Ektron, esta questão é resolvida através da instalação da funcionalidade "Compatibilidade Metabase IIS6" no Windows:
Verifique "funcionalidades do Windows" ou "serviços de papel" para o Metabase IIS6 compatibilidade, adicionar se estiver em falta:
Mau:
DirectoryEntry directoryEntry =
new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com/",
userName, password);
Bom:
DirectoryEntry directoryEntry =
new DirectoryEntry("LDAP://someserver.contoso.com/DC=contoso,DC=com",
userName, password);
Eu também tive este erro e para mim era um OU com uma barra avançada no nome: "File/Folder Access Groups".
Este tópico do fórum apontou-me na direcção certa. No final, chamar {[[0]} em cada valor de caminho antes de usar resolveu o problema para mim.
Só para que saibas, eu tinha o mesmo erro e estava a usar as credenciais correctas mas o meu URL LDAP estava errado: (
Recebi a mesma mensagem de erro e o mesmo código
A solução... ... Instalei a Autenticação Básica para realizar a solução de problemas indicada aqui: https://support.microsoft.com/en-us/kb/329986
E depois disso, as coisas começaram a funcionar. Mesmo depois de eu re-desativar a Autenticação Básica na página que eu estava testando, todas as outras páginas começaram a trabalhar novamente com autenticacao.No que diz respeito, Acácio
O mesmo erro ocorre se na directoria.Patch não é nada depois dos símbolos " LDAP//:". É necessário verificar o directoryEntry.Caminho antes do director-investigação.FindOne (). A menos que explicitamente especificado domínio, e não precisa de "LDAP://".
private void GetUser(string userName, string domainName)
{
DirectoryEntry dirEntry = new DirectoryEntry();
if (domainName.Length > 0)
{
dirEntry.Path = "LDAP://" + domainName;
}
DirectorySearcher dirSearcher = new DirectorySearcher(dirEntry);
dirSearcher.SearchScope = SearchScope.Subtree;
dirSearcher.Filter = string.Format("(&(objectClass=user)(|(cn={0})(sn={0}*)(givenName={0})(sAMAccountName={0}*)))", userName);
var searchResults = dirSearcher.FindAll();
//var searchResults = dirSearcher.FindOne();
if (searchResults.Count == 0)
{
MessageBox.Show("User not found");
}
else
{
foreach (SearchResult sr in searchResults)
{
var de = sr.GetDirectoryEntry();
string user = de.Properties["SAMAccountName"][0].ToString();
MessageBox.Show(user);
}
}
}
DirectoryEntry entry = new DirectoryEntry(path, ldapUser, ldapPassword);
DirectorySearcher searcher = new DirectorySearcher();
searcher.SearchRoot = entry;
searcher.SearchScope = SearchScope.Subtree;
Para isto:
DirectoryEntry entry = new DirectoryEntry(path, ldapUser, ldapPassword);
DirectorySearcher searcher = new DirectorySearcher();
searcher.SearchScope = SearchScope.OneLevel;
SearchResult searchResult = searcher.FindOne();
Encontro este erro quando estou a questionar uma entrada de outro domínio do forrest e este item tem alguma atribuição personalizada do outro domínio.
Para resolver este erro, só preciso de indicar o servidor no URL LDAP:
Localização com erro = LDAP://CN=MyObj,DC=DOMAIN,DC=COM
Localização sem erro : LDAP://domain.com:389/CN=MyObj,DC=Domain,DC=COM