No no no no no no no. And might I add, no.
It's a common misconception that the solution to all Windows problems is a reboot or a restart of something. Sometimes it does fix it, but what have you learned about what caused the problem, and what have you learned about how to fix it properly or how to avoid it in future?
Like Kevin said, first of all give us some more info about your environment. Secondly, let us know what you mean by "when I query LDAP". Are you using some third party tool for this, or submitting an LDAP query in code? There may be something amiss in your LDAP query, and trying to brute-force a fix by just rebooting the server or restarting the LDAP service will never fix it if so. Can you see the user in AD Users & Computers? Can you bind to the DN of the user?
The ASP.NET Active Directory Membership Provider does an authenticated bind to the Active Directory using a specified username, password, and "connection string". The connection string is made up of the LDAP server's name, and the fully-qualified path of the container object where the user specified is located.
The connection string begins with the URI LDAP://.
For the server name, you can use the name of a domain controller in that domain-- let's say "dc1.corp.domain.com". That gives us LDAP://dc1.corp.domain.com/ thusfar.
The next bit is the fully qualified path of the container object where the binding user is located. Let's say you're using the "Administrator" account and your domain's name is "corp.domain.com". The "Administrator" account is in a container named "Users" located one level below the root of the domain. Thus, the fully qualified DN of the "Users" container would be: CN=Users,DC=corp,DC=domain,DC=com. If the user you're binding with is in an OU, instead of a container, the path would include "OU=ou-name".
So, using an account in an OU named Service Accounts that's a sub-OU of an OU named Corp Objects that's a sub-OU of a domain named corp.domain.com would have a fully-qualified path of OU=Service Accounts,OU=Corp Objects,DC=corp,DC=domain,DC=com.
Combine the LDAP://dc1.corp.domain.com/ with the fully qualified path to the container where the binding user is located (like, say, LDAP://dc1.corp.domain.com/OU=Service Accounts,OU=Corp Objects,DC=corp,DC=domain,DC=com) and you've got your "connection string".
(You can use the domain's name in the connection string as opposed to the name of a domain controller. The difference is that the domain's name will resolve to the IP address of any domain controller in the domain. That can be both good and bad. You're not reliant on any single domain controller to be up and running for the membership provider to work, but the name happens to resolve to, say, a DC in a remote location with spotty network connectivity then you may have problems with the membership provider working.)
Best Answer
I wish it was as easy as:
But it's not; AD stores the objectSID as hexadecimal.
The folks on serverfault have written a few answers that may help, though:
Retrieve user details from Active Directory using SID