I did this once for a project -- good luck!
Do you have administrative access to the AD server? you might need it. Make friends with your AD admin :-)
Can you please elaborate more what your project is about?
The question is if you just need your users / applications to authenticate against ActiveDirectory or LDAP,
or if you need your applications to access the data that's stored in ActiveDirectory, and perhaps augment or modify the entries..
If you just need to authenticate, then as Justin pointed out, either an annonymous or password-protected (not much extra value IMHO) bind account on the ActiveDirectory server is all you need. Talk to your ActiveDirectory admin.
If you want to use the contents of ActiveDirectory as the basis of your own user records, and perhaps augment or modify the data, you might need to set up your own LDAP server (because your IT department might not be thrilled by the idea that you modify "their" records...)
ActiveDirectory looks like LDAP and is similar, but there are differences mainly in the schema.
You will run into a couple of problems:
- AD schema and attributes are quite a bit different from the LDAP Standard
- in particular, from what I understand, the AD schema is somewhat pre-defined and fixed, because all the Micro$oft applications require a certain schema...
- there might not be an anonymous access set up by default for AD , as it is for LDAP
(that makes it difficult to just do an LDAP query on the command line to test things out)
You might want to ask your AD Admin to set one up for you
- Your authenticated user accessing AD might not have permission to see all AD records and/or the Schema
I remember that i found tons of inconsistent records in AD, e.g. wrong organizational structure, people records mixed-in with records for machines, devices, software - ugh!! and people records strewn accross the schema (not all people records in just one sub-tree as you would expect in an LDAP schema)
... to be completed ...
If you just need people or applications to authenticate against a Directory, then it might not be worth going through all this hastle -- it's better to just use AD directly via a bind account.
Use the openldap command line tools to try to authenticate against ActiveDirectory on the UNIX command line. That will help you to get a feel for the process and the data that is returned.
let me look at my old project notes and i'll update this
I hope this helps you
to authenticate against OpenLDAP, you'll need to know values of "distinguished name" (dn) of your organization,
"organizational unit" (ou), the "common name" (cn) of the person authenticating, etc.. but I can't give you a full intro here...
It's best to read in the documentation of OpenLDAP here:
http://www.openldap.org/doc/admin24/
it's best to run "ldapsearch" on the command line to try out and verify that you can bind / access LDAP.
http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.0-Release&format=html
or at the IBM site:
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahy%2Frzahyunderdn.htm
In my opinion it has to do with a default setup of samba. Even if you overrode on the single users'record, still a general default is enforcing the max age.
Would you please explore the
sudo ./bin/pdbedit -P "maximum password age"
commands?
Best Answer
Google has led you down the right track. Ideally you want both LDAP for the central user management and Kerberos for it's added security and SSO.
LDAP alone will get you centralized user management but users will still have to re-authenticate with each service they are connecting too. That's where Kerberos comes in which issues the client a ticket which grants the user access to other services once they've been authenticated.
For Kerberos you'll need a stable synchronized time source. So I would start by setting up NTP, DHCP, and DNS properly. Then configure your client workstations to get their NTP from DHCP. Once you know you have a stable time source you can then setup LDAP and Kerberos servers to provide the necessary directory services to pull it together.