Getting the AD authentication working can be a bit delicate, that's for
sure - using the LDAP interface is far easier, but of course, has it's
disadvantages vice AD.
Anyway, I've definitely seen this error before, but since I never write
anything down, can't tell you for certain what the "fix" might be, but
it sounds like it probably lies in your DNS configuration. Some common
problems:
1. Make sure to use the URL of the form ad://domainname - not hostname,
and use the right userid format for binding, i.e. [EMAIL PROTECTED]
2. Run this query:
# nslookup -query=any _ldap._tcp.domainname
This will return SRV records from your DNS server service, and will
include one or more LDAP records (can also find this in your DNS
manager). Make sure you can resolve and connect to all of the servers
listed (sometimes, AD/DNS will enumerate network interfaces that your
server can't reach, so use nslookup to see if there are multiple "A"
records associated with the returned LDAP servers. .)
Also, check:
# nslookup =query=any _gc._tcp.domainname
to ensure you can resolve a Global Catalog server,
3. Make sure you have appropriate reverse lookup zones, with ptr
records for each of your LDAP servers and SGD servers.
4. Test the kerberos config with:
# kinit administrator
Enter the admin password when requested, then run:
# klist
to ensure you've received a TGT.
By the way, if you have support, by all means use it - no sense
suffering in silence. It does work, just AD is particularly cranky
about who it talks to, so
Oh, and I've used Vintela Authentication Services a long time ago, and
recently setup a Solaris 10 authenticating to an R2 AD Catalog Server -
R2 adds the Posix bits to AD, i.e. uid, gid, etc that Unix users need.
Vintela and most others extend the schema as well, but I find it's far
easier to convince your AD administrators to allow Microsoft to extend
the AD schema, (in the form of "R2"), than some random hackers' script
you downloaded from the Internet. I wrote up my procedure if you'd
like to have a look at it, itself, uh, "borrowed" from multiple sources
.. :)
There are other approaches as well (most under the banner of "Identity
Management") which typically replicates account information across your
different authentication systems.
Rick
Trevor Dell wrote:
Hi Christian,
It is a MS DNS, and all those DNS entries exist.
Seen a lot of problems digging around the net and not one success
story, seems like it's a component that just doesn't work. Is there
anyone?
I'm interested in your 'work around'.. I've seen some complex ways to
set up Solaris (is that what you're using?) to authenticate from an
AD. Most were way beyond what we need. Do you have ldap in your
nsswitch.conf, and wrote the queries?
I appreciate the info.
- Trev
Christian McHugh wrote:
I don't have an answer for you but I do have a similar problem.
http://www.mail-archive.com/sgd-users%40filibeto.org/msg00221.html
If you are running the MS DNS it is probably not an issue, but look
at DNS resolution for the DC's, along with the _tcp entries that
should exist.
I've not heard of any solution but we have managed to "work around"
the issue by using unix auth and setting up ad auth for the entire
system. But I would also be glad to see a SGD solution.
Christian McHugh
Northern Arizona University
_______________________________________________
SGD-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sgd-users
_______________________________________________
SGD-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sgd-users
--
Rick Butland
E-Mail: [EMAIL PROTECTED]
AccessLine: (703) 579-1947 x53261
Direct: (703) 444-9398
Mobile: (703) 328-8130
_______________________________________________
SGD-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sgd-users
