[OpenAFS] Re: aklog claims it can't contact KDC, but KDC is issuing tickets
Donny Jekels
djekels@gmail.com
Tue, 7 Mar 2006 17:06:29 -0600
------=_Part_12025_25832820.1141772789388
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi,
I am trying to get AFS to authenticate using AD, since we're already using
AD to authenticate to all our Linux boxes with kerberos and ldap. the final
step now is to setup a AFS cell with one server today and share users home
directories.
upon loing wiht their kerberos tgt's to also automount their afs home
directories.
does anyone if this has been done and working? if so please send links to
docs/howtos/examples etc.etc
kind regards
Donny
On 3/7/06, Marcus Watts <mdw@umich.edu> wrote:
>
> Ken Hornstein <kenh@cmf.nrl.navy.mil> replied to Adam:
> > >Just got some results back. Most importantly, I got the ktrace.out
> > >(MacOS equivalent of truss/strace dump) from the user. I'm going to
> > >analyze it this afternoon. Getting a traceroute packet dump is going
> > >to be more of a challenge since MacOS doesn't ship with traceroute
> > >(argh!).
> >
> > Do you really want a traceroute packet dump, or a tcpdump packet dump?
> > In my experience, the system call tracer won't be very much help; I am
> > sure all it will tell you was that it sent packets to your KDC, but it
> > never saw any replies. You already know that.
>
> traceroute is going to be of limited value here. traceroute
> is good at telling what routers a working connection might
> traverse on the outbound path. What you want to know here is how udp
> packets
> fail to get returned. Traceroute (done both directions) may help you to
> identify where a nat or firewall rule is that you care about, but it won'=
t
> tell you where udp packets are actually getting dropped.
>
> ktrace will admittedly have a low signal to noise ratio. However, it
> should say which IP address kinit/aklog tried to reach
> and will definitely have what files kinit/aklog read to decide
> to go after those IP addresses. Since we're talking MacOS
> here, those files do have unobvious pathnames - presence of files like
> /Users/mdw/Library/Preferences/edu.mit.Kerberos
> can have interesting consequences, and this stuff might change
> between binaries (since they're probably built by different people.)
>
> I think tcpdump is likely to be the most interesting thing to
> start with. That will identify which ip addresses & ports matter
> which will help in going after the nat configuration.
>
> Of course, without physical access or a knowledgeable user,
> a nat problem may be difficult to solve.
>
> -Marcus
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>
------=_Part_12025_25832820.1141772789388
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Hi,<br><br>I am trying to get AFS to authenticate using AD, since we're alr=
eady using AD to authenticate to all our Linux boxes with kerberos and ldap=
. the final step now is to setup a AFS cell with one server today and share=
users home directories.
<br><br>upon loing wiht their kerberos tgt's to also automount their afs ho=
me directories.<br><br>does anyone if this has been done and working? if so=
please send links to docs/howtos/examples etc.etc <br><br>kind regards
<br>Donny<br><br><div><span class=3D"gmail_quote">On 3/7/06, <b class=3D"gm=
ail_sendername">Marcus Watts</b> <<a href=3D"mailto:mdw@umich.edu">mdw@u=
mich.edu</a>> wrote:</span><blockquote class=3D"gmail_quote" style=3D"bo=
rder-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding=
-left: 1ex;">
Ken Hornstein <<a href=3D"mailto:kenh@cmf.nrl.navy.mil">kenh@cmf.nrl.nav=
y.mil</a>> replied to Adam:<br>> >Just got some results back. =
; Most importantly, I got the ktrace.out<br>> >(MacOS equivalent=
of truss/strace dump) from the user. I'm going to
<br>> >analyze it this afternoon. Getting a traceroute pac=
ket dump is going<br>> >to be more of a challenge since MacOS doesn't=
ship with traceroute<br>> >(argh!).<br>><br>> Do you really wa=
nt a traceroute packet dump, or a tcpdump packet dump?
<br>> In my experience, the system call tracer won't be very much help; =
I am<br>> sure all it will tell you was that it sent packets to your KDC=
, but it<br>> never saw any replies. You already know that.<b=
r><br>
traceroute is going to be of limited value here. traceroute<br>i=
s good at telling what routers a working connection might<br>traverse on th=
e outbound path. What you want to know here is how udp packets<b=
r>fail to get returned. Traceroute (done both directions) may he=
lp you to
<br>identify where a nat or firewall rule is that you care about, but it wo=
n't<br>tell you where udp packets are actually getting dropped.<br><br>ktra=
ce will admittedly have a low signal to noise ratio. However, it=
<br>should say which IP address kinit/aklog tried to reach
<br>and will definitely have what files kinit/aklog read to decide<br>to go=
after those IP addresses. Since we're talking MacOS<br>here, th=
ose files do have unobvious pathnames - presence of files like<br> &nb=
sp; /Users/mdw/Library/Preferences/edu.m=
it.Kerberos
<br>can have interesting consequences, and this stuff might change<br>betwe=
en binaries (since they're probably built by different people.)<br><br>I th=
ink tcpdump is likely to be the most interesting thing to<br>start with.&nb=
sp; That will identify which ip addresses & ports matter
<br>which will help in going after the nat configuration.<br><br>Of course,=
without physical access or a knowledgeable user,<br>a nat problem may be d=
ifficult to solve.<br><br> &=
nbsp; &nbs=
p; &=
nbsp; -Marcus
<br>_______________________________________________<br>OpenAFS-info mailing=
list<br><a href=3D"mailto:OpenAFS-info@openafs.org">OpenAFS-info@openafs.o=
rg</a><br><a href=3D"https://lists.openafs.org/mailman/listinfo/openafs-inf=
o">
https://lists.openafs.org/mailman/listinfo/openafs-info</a><br></blockquote=
></div><br>
------=_Part_12025_25832820.1141772789388--