ldap - find out details of a user - ldap

One of my clients wants to know why a user can not log in to the portal.
The portal uses the client's LDAP.
Is there a tool/command to run against their Active Directory which will spit out details of the configured user such as permissions/granted hosts and etc?

What are you looking for?
An API do to this in a programming environment? If so: which one??
A Windows command-line tool? There's Joeware's ADFind - part of a whole suite of free AD tools - which is quite amazing - check it out!

Related

Test LDAP connection with sample users

I don't know much about this topic, is the first time when I need to do this.
I have a platform (an e-commerce website) with the LDAP extension added, I must test to see if LDAP is working.
I understood that I need an active directory…but I really don’t understand or I don’t know how to search to get something that can be useful.
I need some test users to see if LDAP protocol is working...
Do you have any tutorials or documentation about this? Like, for dummies :)
Thank you
There's a public test LDAP server detailed at https://www.forumsys.com/tutorials/integration-how-to/ldap/online-ldap-test-server/
That's not Active Directory, so no good if you have a specific requirement to test Active Directory LDAP. I doubt you'd find a public Active Directory for testing -- you may be able to use a free trial of Windows Server 2019 (or free trial in MS's Azure cloud) to set up a Windows server on which you create a AD test domain.

Google Cloud Directory Sync and AD link through LDAP

I have been working to link my AD to G-Suit and have an auto sync established. The reason I put this here because I have had hard time to figure out everything. I am still not at the end of this procedure and I would appreciate if the skilled people would contribute to help me and I guess many others as well, on this topic.
I downloaded GCDS tool (4.5.7) and installed on a member server. Tried to go through the steps and failed, except to the first one to authenticate to Google.
Learnt: It is a Java (Sun) based product and when it come to authentication or SSL it will through errors that need to be sorted.
Step 1, Google Auth - done and very simple as long as you can logon to your GAE account
Step 2, LPAD config... this was tricky
I created a service account to use
Learnt:
You need to have the SAMS account matching with the displayname and name as well; only this way I could authenticate.
In most cases you don't need any admin rights, a domain user should be able to read the DN structure from LDAP.
I have the OU structure, but I need LDAP working on the DC (this works somehow)
Learnt:
Simple connection through port 389;
SSL would use port 636;
in most cases
GCDS only uses Simple authentication!
Learnt:
With port 389
Domain group policy needed to changed to non LDAP auth required (Domain controller: LDAP server signing requirements changed to none!) to be able to logon - this one is working and good for DEVSERV
Question: Should I use it for PRODSERV or I need to aim to use SSL?
Learnt:
With port 636 (SSL) you need a certificate
Question: I tried to add self cert based on the following article, added to the trusted cert root but Google cannot see it?
BASE DN can be read out through LDP.EXE (built in LDAP browser by MS)
Learnt:
You can add your OU you wanted doesn't have to be the root of the tree
Question: does it mean you have implemented extra security?
Step 3,Defining what data I can collect. OU and person I picked.
Learnt
Profile will collect extra information to Google, such as job title, phone etc. I only wanted them for the company signature... Well that is still not clear if this can be done. If that is not possible, I can't see the reason why I should disclose unwanted information to store on another server.
Question: Can job description be included to the Google Mail signature?
I am keep adding my finding to it as I am working through but would appreciate any input from people who managed to set it up.
Step 4, Searching in the Organisation Unit - confusing again but it is done. (More to follow.)

Secure/second access for web development - deny view for public; allow developer

Sorry for the strange title, I can't find better description to my question.
I'm building some websites with a team of 4 persons - 2 developers and 2 testers. The developers build the page on a local apache/mysql server. Every now and then they upload a snapshot of what they have done to a dedicated server, that serves the files with htaccess basic authentification to the testers.
Are there better solutions for this workflow? I would like to have more security for this whole thing. The snapshots of the website often show debug-/development info, that shouldn't be seen by public eyes.
Something like a different port of the apache server... ? Any suggestions?
I think other way is to use Git or some other versioning system for deployment, so only new code will be added and you can disable showing of these debug informations permanently in some file which will not be overwritten.
OR
You can use some cloud service like getpantheon.com (for Drupal). It could provide you good environment for testing.

Granular access control for MediaWiki with LDAP

My company has a MediaWiki setup which we are looking to make [partially] client accessible. Ideally each client would be able to see only their own page. Our wiki requires the user to be logged into view or edit, and we have the LDAP plugin (This one, specifically) so we can use our Active Directory credentials.
I see this question has come up before a few years ago, but I didn't see an question dealing with LDAP in particular. Can we manage a specific AD account if we give clients one on our domain for this purpose? Alternatively, is there a way to give clients a login directly into the wiki (sort of like logging locally into the computer, instead of the domain), that we could control the access rights of?
For reference: we are on MediaWiki version 1.19.1, PHP version 5.3.15, MySQL version 5.0.96-winx64, and the installation is running on Windows Server 2008 R2 x64 (IIS 7.5).
Thanks very much for the help!
You can use local accounts in addition to the LDAP accounts to log users in. You have to set $wgLDAPUseLocal to true in your LocalSettings.php. Basically, it adds another option to the domain drop down box on the login form that says "local". Users that want to log in with a local wiki account use that. I would also disable account creation on the wiki and create accounts manually for your clients.
Regardless of whether you use local accounts or AD accounts, for page-level access control, you would have to use one of these extensions. Extension:AccessControl seems to be a popular one.

Access to manage-account commands in OpenDS

OpenDS provides command-line access to many necessary account functions via its manage-account utility. For example, to disable an account:
manage-account set-account-is-disabled --operationValue true
--baseDN uid=someuser,ou=People,dc=example,dc=com" --hostname hostname --port 389
--bindDN "cn=Directory Manager" --bindPassword password
This is fine and dandy is you have a sysadmin to administer your ldap server but in a scenario where you have 1000s of users all over the globe this becomes a problem (imagine a user locked out of their account in Japan while the sysadmin is asleep in the US). We'd like to be able to programmatically tie into some of these manage-account functions so we can provide local admins/managers the ability to manage their own users.
Can anybody provide any insight on if this is possible and if so how? We are writing this in C# and I can't find any examples on it. Looking at the .NET API docs I thought System.DirectoryServices.Protocols.ExtendedRequest looked promising but cannot figure out how to use it.
Any help would be greatly appreciated, thanks!
The Manage-Account tool uses an LDAP extended operation, which code is in opends/src/server/org/opends/server/extensions/PasswordPolicyStateExtendedOperation.java.
Alternately, you can check the OpenDJ LDAP SDK, which has support for the extended operation, and will allow you to quickly write a client application.
OpenDJ LDAP SDK is documented at http://opendj.forgerock.org/opendj-ldap-sdk/ (and the doc is in the developer's guide : http://opendj.forgerock.org/doc/dev-guide/OpenDJ-Dev-Guide.html).
Regards,
Ludovic
The source code for manage-account is available, one can re-create the encodings from there. Also, one could set up a directory server, run manage-account, record the steps the tool takes from the access log, then write code to re-create those steps.