How to create an LDAP server based on an existing one that I don't have direct access to...

Hello all – I’m going to break this post up into different sections so it’s easier to read/follow.

BACKGROUND – I work for a big copier/printer company.  We use ServiceDesk Plus (SDP) as our ticketing software here at our helpdesk.  Currently, the only thing we use it for is to keep track of helpdesk tickets, but it has a lot more functionality.  I’ve recently been tasked with utilizing some of its more advanced features.  To help facilitate that endeavor, it has become necessary to create unique accounts (2000+) within SDP for each of our employees.  This would be easy if all of our employees were on a domain/Active Directory that I had direct access to (AD accounts are currently controlled by a 3rd party).  I do not.  And I’m not about to do that much data entry manually if I can avoid it.  Part two of my assignment is to demonstrate how our copiers can copy/scan documents and email them directly to a company employee using LDAP.  Again, this would be easy if I had admin access to our AD/Exchange.  I do not.

OBJECTIVES – In short, my objectives are to create 2000+ SDP accounts, and create my own LDAP server that I can use to access from our copiers/printers for demo purposes.  In my world, it seems to me that I should be able to link the two objectives.  If you’re asking yourself how/why the two are even related, it’s because I need to regularly be able to update the accounts in SDP as employee turnover happens.  Rather than making manual updates as needed, I would like to just run an export/import from an LDAP server to the SDP server.  This is where I would hopefully accomplish two objectives with one solution.  The copiers could access the LDAP server I setup, and I can regularly run updates to the SDP server via this same LDAP server.  How do I populate the LDAP server you might ask?  See my “dilemma” below.

DILEMMA – I do not have access to the domain accounts, so I cannot just do a straight export/import into SDP.  And as may or may not be inherently obvious, the same people who control all of our domain accounts, control our MS Exchange accounts as well.  So the only thing that I DO have access to with regards to identifying all of our employees, is the Global Address Book.  </BeginSarcasm>Yay</EndSarcasm>.

BRAINSTORM - The “solution” I have worked out in my head and the part where I need help is this: I can download the GAB to my workstation.  I can then export that out to a text file of some sort which I can then use to populate an LDAP (maybe even just setup a local AD server here locally?) server with.  I think?  So my question then, first of all, does this all make sense?  Second, is what I’m thinking possible, and if so, what would be the best solution for an LDAP server in this case?  Keep in mind, that these accounts, both on the LDAP server and the SDP server are (at least for the time being), purely for internal use.  They are not meant to replace and/or administer the real AD/Exchange accounts managed by the aforementioned 3rd party.  It does not need to be highly secure as it will mainly be for demo purposes, but it does need to be functional in the sense that the email accounts associated with the accounts on the LDAP need to be the same as the real AD/Exchange accounts.

Thank you in advance for any help and please let me know if anything I've written here needs clarification.

Who is Participating?
GundogTrainerConnect With a Mentor Commented:
Part 1
just go with this for a moment...
if you are logging onto the AD with a normal user account this by default has enough rights to read the AD attributes by using LDAP. I would expect that all the Domain controllers will accept and process LDAP requests.

Therefore if you could get a non-expiring account for MFD then this would probably be able to lookup the users and email addresses nativley - it just needs a servername of a Domain Controller and a normal username and password. You dont need to ask the 3rd party for anything special or tell them what your doing ! (been there before).

Part 2.
OK so you still want to harvest the information from AD to do somthing with it, maybe to populate an ADAM instance or database etc but lets worry about getting some data first.

Attached is a basic vbscript to retrieve basic user properties from Active Directory.
Copy the code to your PC and save it as a text file named something like "adquery.vbs" the important bit is the .vbs suffix.
you will need to edit it - if you are logged onto the same domain you can set the username and passord to an empty string by
but you need to provide the name of a domain controller in line 3 - if you dont know one then you could use the full domain name eg. domain.local

OK, if you open a command prompt and navigate to where the adquery.vbs file is saved run the following:
cscript.exe adquery.vbs
this should start filling the screen with data, to pipe it to a file type
cscript.exe adquery.vbs > log.txt

If you let me know how you get on.
LdapDC   ="DC-1"

 strSQL = "<LDAP://" & LdapDC & ":389>;(&(mail=*)(objectclass=user)(objectclass=person));mail,sn,givenname,displayname;subtree"
 Set LdapConn = CreateObject("ADODB.Connection")
 Set LdapCommand = CreateObject("ADODB.Command")
 LdapConn.Provider = "ADSDSOObject"
 Ldapconn.Open "Active Directory Provider" ,LdapConUN,LdapConPW
 set LdapCommand.Activeconnection = LdapConn
 LdapCommand.commandtext = strSQL
 LdapCommand.Properties("Page Size")=100
 Set LdapRs = LdapCommand.Execute

 wscript.echo LdapRsrecordcount 

  Do While Not LdapRs.EOF Or LdapRs.BOF
    wscript.echo chr(34) & strEmail & chr(34) & ""","""& strFName & """,""" & strSName & """,""" & strDisplay & """"

Open in new window

GundogTrainerConnect With a Mentor Commented:
Quick questions:
1. You dont have admin access to the AD - to query AD with LDAP you only need user level access depending on the properties your trying to return. Therefore do you have any access to the AD ?

2. You could create an ADAM instance on a server - this is an active directory in Application mode - you could populate this with the details without someone telling you to buy another 2000 microsoft user licences etc - if the 3rd party own the CALS etc.

do you need to configure any specific properties on the LDAP or are you just using it to query the name to return an email address etc.
I would tend to say if you can connect tio the real AD with a user account that "DOES NOT HAVE ANY WRITE ACCESS" then you can only read it and does it matter if they dont like it.

Oh and yes, if you know the attributes you want it is fairly easy to write a script to extract the data and import it into the dummy LDAP.
And another script to go through the dummy and delete any account that arnt in the live AD etc.
BpcAdamAuthor Commented:
Thank you for the response Gundog.  I think I can see where your proposed solution might help me out, but I'm not sure how I would go about querying the AD server.  What tool(s) would I need to do that?  I don't have RDP access or anything like that and the server is a couple thousand miles away, so no physical access either...

The only thing I need the LDAP for is so I can point our copiers there when our sales team needs to demo the LDAP functionality to a potential customer.  But since I have to create 2000+ accounts in our SDP server, I thought I would kill two birds with one stone.  Create the accounts using the GAB as the source, since I can import into ServiceDesk Plus using LDAP, or via some sort of text file.

I'm thinking that using ADAM as you suggested would be the best choice as this would make things quite a bit easier in both scenarios as they both have import/export functionality built around using AD/LDAP.

So I guess the question at this point is: how do I query the AD server without direct access to it?
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

BpcAdamAuthor Commented:
Sorry for my slow responses.  Very busy here at work.

When I try to run that script, I get a message that reads "LDAPConnect.vbs(23, 2) Provider: Table does not exist."

I don't know if it makes a difference, but the workstation that I use does not connect to that domain.  We are on our own local domain, but connected on the same subnet.  I do not authenticate to the DC that I'm trying to query.  The only time that I authenticate to it is when I connect to my email.

I've tried substituting the IP address of the exchange server in place of its name in the script you provided, but that didn't seem to make a difference.  I get the same error.
GundogTrainerConnect With a Mentor Commented:
If you try and populate the :

LdapDC   ="DC-1"

with the credentials you use for email - the Exchange server is probably not a domain controller and if your not logging onto the domain it makes it harder to identify the name of a DC.
You could see if you are able to resolve the domain name if you ping it, if it resolves you could user the domain name as the DC as it should resolve to a domain controller.
BpcAdamAuthor Commented:
I have been pulled away to other tasks and so have to put this on the back burner for the moment.  We did however setup another LDAP server, so I think with the information you've provided me thus far, I can close this topic. I'm awarding partial points for a couple of your answers since they didn't get me all the way there, but they got me a lot further than I would have otherwise and I should be able to incorporate at least some of what you suggested here when I have a chance to get back to this project.  Thanks for all your help.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.