resending this message since it got stuck in mailman.
originally sent by Rick Butland.
> -------- Original Message --------
> Subject: Re: [SGD-Users] AD integration fun
> Date: Thu, 10 May 2007 15:22:45 -0400
> From: Rick Butland <[EMAIL PROTECTED]>
> To: <[email protected]>
According to the doc I've read, this failure can be caused by a reverse
lookup failure - try nslookup ipaddr-of-ad01 from the SGD server.
As I've mentioned, if you're allowing dynamic updates to your DNS server
service, sometimes, interfaces that aren't reachable from your SGD
system might be being mapped - (this recently happened to me when I
created an ESX private interface on my Windows server) - an nslookup on
ad01.example.com should only return a single IP address, or, at least,
each of the IP addresses should be reachable from the SGD server. Then,
I'd try telnet'ing to the service ports from your SGD system, just to
make sure there's not a firewall somewhere along the way, e.g.
telnet ipaddr 389
telnet ipaddr 3268
and make sure you can connect.
I also read a note from someone who said this error was caused by him
setting the base domain attribute in the Login Authority screen, and
removing it resolved the issue - doesn't really sound right, but what
the heck, might be worth a try.
All else fails, enabling logfilters might help, specifically:
server/ldap/*:filename.log
server/kerberos/*:filename.log
server/login/*:filename.log
Run a "tarantella archive" to archive your current logs, then enable
this filters, and try to login using AD credentials, and then review
these logs.
Finally, there's a packet-level trace that can be turned on to monitor
the conversation between SGD and the LDAP server. Not sure I want to
put that out publicly, tho, and you can always use Ethereal to monitor
the conversation on 3268 and 389 between the two servers.
Yup, I basically used Scott Lowe's blog entry, and added a few details
to make it more "step-by-step". I've never really finished the doc,
(it's to be a chapter of a larger doc) so consider it a draft,
unreviewed, with no warranty or guarantees. And since I notice that the
doc doesn't yet credit Scott, consider it done here. With that raft of
disclaimers, I've attached a pdf of the relevant section, hope you find
it useful.
Rick
_______________________________________________
SGD-Users mailing list
[email protected]
http://node1.filibeto.org/mailman/listinfo/sgd-users
