Professional Documents
Culture Documents
GSS-‐TSIG
(3.7.1
/
6.7.1
and
later)
Last
update:
August
7,
2012
INTERNAL AND CONFIDENTAL - NOT FOR DISTRIBUTION
System
specifications
VM
Version
RAM
IP
Notes
Proteus
3.7.1
4GB
172.21.12.101
Adonis
6.7.1
1GB
172.21.12.110
DHCP
master
Adonis
6.7.1
1GB
172.21.12.111
DHCP
failover
Windows
DC
2008
EE
R2
2GB
172.21.12.115
AD
/
DNS
primary
Windows
7
1GB
172.21.12.116
DHCP
client
All
of
these
VM’s
are
hosted
in
VMware
Lab
Manager
(torvlmw01.bluecatnetworks.corp)
and
available
only
to
Tim
Krzywonos
and
Tyler
Wheeler
1. Adonis
DHCP
with
Microsoft
DNS
-‐
Covered
in
this
document
• Kerberos
Server
on
Microsoft
DC
• Microsoft
DNS
2003
/
2008
(32/64
bit)
• Adonis
DHCP
(Managed
by
Proteus
Server)
NO
XHA
• Proteus
v3.7.0
P3
or
newer
only
2. Adonis
DNS
with
Microsoft
DHCP
–
Not
covered
in
this
document
• Kerberos
Server
on
Microsoft
DC
• Microsoft
DHCP
2003
/
2008
(32/64
bit)
• Adonis
DNS
(Managed
by
Proteus
Server)
NO
XHA
• Proteus
v3.7.0
P3
or
newer
only
3. Adonis
DNS/DHCP
–
Not
covered
in
this
document
• Kerberos
Server
on
Microsoft
DC
• Adonis
DNS
(Managed
by
Proteus
Server)
NO
XHA
• Adonis
DHCP
(Managed
by
Proteus
Server)
NO
XHA
• Proteus
v3.7.0
P3
or
newer
only
Kerberos
Server
The
KDC
software
is
installed
on
a
server
machine
–
Kerberos
Server.
The
client
applications
(such
as
a
DDNS
client)
communicate
with
the
KDC
server
in
order
to
be
able
to
authenticate
themselves
to
the
server
applications
(such
as
a
DNS
server).
Server
applications
may
not
need
to
communicate
with
the
KDC,
as
they
usually
hold
a
long-‐term
key
that
allows
them
to
ensure
the
client
is
trusted
by
KDC.
There
are
two
mainstream
KDC
implementations,
one
by
Microsoft,
and
the
other
by
MIT.
Proteus/Adonis
components
were
only
tested
with
Microsoft
KDC,
but
there
is
no
technical
reason
why
it
shouldn’t
work
with
the
MIT
Kerberos
server
implementation.
Kerberos
Clients
Kerberos
Clients
are
the
client
and
server
applications
(such
as
DNS
clients
and
servers)
that
communicate
with
the
KDC
(or
Kerberos
Server)
in
order
to
authenticate
each
other.
Kerberos
Clients
use
a
Kerberos
library
for
this
purpose
(both
Microsoft
and
MIT
provide
such
libraries).
On
Linux,
the
MIT
Kerberos
library
is
provided
as
part
of
the
installation
in
the
libkrb5
package.
Adonis
servers
use
this
Kerberos
library
via
the
following
shared
objects:
/usr/lib/libkrb5.so
and
/usr/lib/libkrb5support.so.
On
Adonis
the
MIT
Kerberos
library
is
configured
using
a
configuration
file
that
is
usually
located
in
/etc/krb5.conf.
This
file
contains
the
IP
address
or
host
name
of
the
KDCs,
and
other
information
that
the
client
or
server
applications
may
need
to
communicate
with
the
KDC
and
authenticate
each
other.
Both
client
and
server
applications
are,
in
Kerberos
terms,
principals.
Both
have
records
in
the
Kerberos
database,
and
a
password
to
authenticate
them
to
the
KDC.
Non-‐interactive
applications
usually
use
“long-‐term”
keys
that
are
derived
from
their
respective
passwords.
For
example,
when
a
DHCP
server
Kerberos
Realms
Much
like
the
Microsoft
Windows
domains,
Kerberos
has
the
ability
to
divide
the
network
in
groups
or
“realms”.
This
separation
is
made
to
avoid
too
many
requests
being
sent
to
a
single
KDC,
which
would
become
a
bottleneck
for
the
authentication
service
and
thus
for
the
whole
network.
The
realm
name
is
typically
mapped
to
the
Domain
Name
of
the
network
(DNS),
or
to
sub-‐domain
names,
although
this
is
not
mandatory
it
is
the
recommended
approach.
Each
Kerberos
realm
typically
contains
at
least
one
mapped
Service
Principal
Name
(SPN).
This
is
an
item,
user
or
service,
which
needs
to
be
authenticated.
An
example
of
a
SPN
is
below:
Principal/instance@REALM.
COM
Note:
The
realm
is
commonly
written
in
capital
letters
to
differentiate
the
Domain
Name
from
the
Kerberos
realm.
As
a
best
practice
your
realm
names
should
be
capitalized.
2 Database
5
Authentication
Ticket
Granting
Service Service
Q
3
A _REQ
EP
_ RE REP
S _R
GS S_
4
T 6
TG
S
1
A
Client Server
libkrb5.so 7
AP_REQ libkrb5.so
krb5.conf krb5.conf
8
AP_REP
krb5.keytab krb5.keytab
GSSAPI
What
is
GSSAPI
The
Generic
Security
Services
Application
Program
Interface
(GSSAPI,
also
GSS-‐API)
is
an
application
programing
interface
for
programs
to
access
security
services,
such
as
Kerberos,
NTLM,
and
others
(the
dominant
underlying
security
mechanism
used
with
GSSAPI
is
Kerberos).
The
GSSAPI,
by
itself,
does
not
provide
any
security.
Instead,
security
service
vendors
(such
as
MIT
and
Microsoft)
provide
this.
These
are
usually
in
the
form
of
libraries
installed
with
their
security
software.
These
libraries
presenta
GSSAPI-‐compatible
interface
to
application
writers
who
can
write
their
application
to
use
only
the
vendor-‐independent
GSSAPI.
If
the
security
implementation
ever
needs
replacing,
the
application
need
not
be
rewritten.
On
Linux,
the
MIT
Kerberos
package
mentioned
earlier
includes
a
GSSAPI
implementation
for
Kerberos
as
a
separate
shared
object:
/usr/lib/libgssapi_krb5.so.
The
Client
and
Server
applications
that
need
to
authenticate
each
other
can
use
the
GSSAPI,
rather
than
the
Kerberos
libraries
directly.
In
this
case,
the
Client
application
(e.g.
DHCP
server
updating
DNS)
would
use
the
GSSAPI
library
installed
on
the
DHCP
server
machine
and
the
server
application
(e.g.
DNS
Server)
would
use
the
GSSAPI
library
installed
on
the
DNS
server
machine.
• GSS_Acquire_cred -‐ obtains the user's identity proof, often a secret cryptographic key
The GSSAPI has been standardized for the C (RFC 2744) and Java (JSR-‐072) languages.
GSS-‐TSIG
What
is
GSS-‐TSIG?
GSS-‐TSIG
(Generic
Security
Service
Transaction
Signature)
is
an
algorithm
based
on
GSSAPI
that
allows
the
DNS
Client
and
Server
applications
to
securely
exchange/establish
a
key
for
securing
DNS
transactions.
GSS-‐TSIG
specifies
exactly
how
the
Client
and
Server
applications
exchange
the
GSSAPI
tokens
in
order
to
establish
a
GSS
security
context;
this
is
done
via
TKEY
DNS
queries;
recall
that
GSSAPI
did
not
provide
for
this
• How
the
Client
application
should
use
the
established
GSS
security
context
to
sign
the
DNS
requests
and
validate
the
signatures
on
the
DNS
responses
• How
the
Server
application
should
use
the
GSS
security
context
to
validate
the
DNS
request
signatures
sent
by
the
DNS
clients,
and
generate
the
signatures
for
DNS
responses
1
AS_REQ
Entry
point
for
2
Lookup
First
DHCP
query
Client
Pwd resulting
in
a
3
AS_REP secure
DDNS
update
4
Acquire
DHCP
Server
Credential
5
DHCP
Server
GSS
Credential
6
Initialize
Security
Context
7
TGS_REQ
8
Lookup
Server
Pwd
9
TGS_REP
10
Return
Token
(including
TGS)
11
TKEY
Request
(AP_REQ)
(containing
returned
Token
with
TGS)
12
Accept
Security
Context
13
Accept
Result,
Token
14
TKEY
Response
(AP_REP)
(containing
result,
and
Token)
15
Initialize
Security
Context
16
Return
Token
Save
Security
Context
26
Generate
Response
Signature
27
Signature
Security
Information
Roles
Summary
Features
DNS
Manager
The
DNS
Manager
can
be
found
in
the
Administrative
Tools
folder
or
in
the
Server
Manager.
Below
shows
the
forward
zones
for
“w00t.com”
and
the
reverse
zone
12.21.172.in-‐addr.arpa
(The
reverse
for
the
172.21.12.0
/24
network).
Note:
Added
additional
forward
DNS
entries.
They
were
created
for
all
of
our
BlueCat
systems
used
in
our
config.
Note:
Added
forward
DNS
entries
below.
They
were
created
when
we
added
the
forward
entries.
Weselected
the
option
to
automatically
create
the
reverse
“PTR”
records.
Below
shows
the
adonis1
is
a
Member
of
the
“Domain
Users”
for
“w00t.com/Users”
/replicated/etc/krb5.keytab
Krb5.keytab
is
a
Kerberos
keytab
file
containing
pairs
of
Kerberos
principals
and
encrypted
keys,
which
are
derived
from
the
Kerberos
password.
You
can
use
this
file
to
log
into
Kerberos
without
being
prompted
for
a
password.
The
most
common
personal
use
of
keytab
files
is
to
allow
scripts
to
authenticate
to
Kerberos
without
human
interaction
or
the
storing
of
a
password
in
a
plaintext
file.
Note:
Since
this
is
a
binary
file,
we
will
not
show
the
contents
of
the
file
here.
• nameserverthis is the IP address of the Windows DNS server.
Note:
This
has
to
be
added
manually
and
is
required
for
option
1
from
the
“supported
GSS-‐TSIG
configurations”
list
noted
above
(page
5).
/etc/hosts
The
hosts
file
is
a
static
table
lookup
for
hostnames.
This
simple
text
file
associates
IP
addresses
with
hostnames,
one
line
per
IP
address.
For
each
host
a
single
line
should
be
present
with
the
following
information:
IP_address
canonical_hostname
[aliases...]
The
kinit
command
obtains
or
renews
a
Kerberos
TGT.
The
KDC
options
specified
by
the
[kdcdefault]
and
[realms]
in
the
Kerberos
configuration
file
(krb5.conf)
are
used
if
you
do
not
specify
a
ticket
flag
on
the
command
line.
If
you
are
not
renewing
an
existing
ticket,
the
command
reinitializes
the
credentials
cache
and
will
contain
the
new
ticket-‐granting
ticket
received
from
the
KDC.
The
typical
usage
example
below
has
verbose
output
and
specifies
the
keytab
file
to
use
with
the
service
principal
name.
Typical
usage
kinit
-‐Vkt
/replicated/etc/krb5.keytab
DHCP/adonis1.w00t.com@W00T.COM
Output
adonis1:/#
kinit-‐Vkt
/replicated/etc/krb5.keytab
DHCP/adonis1.w00t.com@W00T.COM
Authenticated
to
Kerberos
v5
Command
options
Usage
kinit
[-‐5]
[-‐4]
[-‐V]
[-‐l
lifetime]
[-‐s
start_time]
[-‐r
renewable_life]
[-‐f
|
-‐F]
[-‐p
|
-‐P]
[-‐a
|
-‐A]
[-‐v]
[-‐R]
[-‐k
[-‐t
keytab_file]]
[-‐c
cachename]
[-‐S
service_name][-‐X
<attribute>[=<value>]]
[principal]
Options
Valid
with
Kerberos
version
-‐5
Kerberos
5
(available)
-‐4
Kerberos
4
(available)(Default
behavior
is
to
try
Kerberos
5)
-‐V
(verbose)Either
4
or
5
-‐l
(lifetime)
Either
4
or
5
-‐s
(start
time)
5
-‐r
(renewable
lifetime)
5
-‐f
forwardable)
5
-‐F
(not
forwardable)
5
-‐p
(proxiable)
5
-‐P
(not
proxiable)
5
-‐a
(include
addresses)
5
-‐A
(do
not
include
addresses)
5
-‐v
(validate)
5
-‐R
(renew)5,
or
both
5
and
4
-‐k
(use
keytab)
5,
or
both
5
and
4
-‐t
(filename
of
keytab
to
use)
5,
or
both
5
and
4
-‐c
(Kerberos
5
cache
name)
5
-‐S
(service)
5,
or
both
5
and
4
-‐X
<attribute>[=<value>]
5
Typical
usage
klist
-‐ket
/replicated/etc/krb5.keytab
Additional
usage
klist
-‐e
Typical
usage
ktpass
-‐princ
DHCP/adonis1.w00t.com@W00T.COM
-‐mapuser
adonis1@W00T.
-‐ptype
KRB5_NT_PRINCIPAL
-‐crypto
AES256-‐SHA1
-‐kvno
8
-‐pass
Password123
-‐out
adonis1.keytab
Command
options
Most
useful
arguments
[-‐
/]
out
:
Keytab
to
produce
[-‐
/]
princ
:
Principal
name
(user@REALM)
[-‐
/]
pass
:
password
to
use
use
'*'
to
prompt
for
password.
[-‐
+]
rndPass
:
...
or
use
+rndPass
to
generate
a
random
password
[-‐
/]
minPass
:
minimum
length
for
random
password
(def:15)
[-‐
/]
maxPass
:
maximum
length
for
random
password
(def:256)
Less
useful
arguments
[-‐
/]
mapuser
:
map
princ
(above)
to
this
user
account
(default:
don't)
[-‐
/]
mapOp
:
how
to
set
the
mapping
attribute
(default:
add
it)
A
command-‐line
tool
that
is
built
into
Windows
Server
2003
/
2008
and
is
available
if
you
have
the
Active
Directory
Domain
Services
(AD
DS)
server
role
installed.The
setspn
tool
Reads,
modifies,
and
deletes
the
Service
Principal
Names
(SPN)
directory
property
for
an
Active
Directory
service
account.
You
use
SPNs
to
locate
a
target
principal
name
for
running
a
service.
You
can
use
the
setspntool
to
also
view
the
current
SPNs,
reset
the
account's
default
SPNs,
and
add
or
delete
supplemental
SPNs.
Typical
usage
setspn
–A
DHCP/adonis1.w00t.com@W00T.COM
adonis1
Command
options
setspn
[modifiers
switch]
[accountname]
Where
"accountname"
can
be
the
name
or
domain\name
of
the
target
computer
or
user
account
Edit
Mode
Switches
-‐R
=
reset
HOST
ServicePrincipalName
Usage:
setspn
-‐R
accountname
-‐A
=
add
arbitrary
SPN
Usage:
setspn
-‐A
SPN
accountname
-‐S
=
add
arbitrary
SPN
after
verifying
no
duplicates
exist
Usage:
setspn
-‐S
SPN
accountname
-‐D
=
delete
arbitrary
SPN
Usage:
setspn
-‐D
SPN
accountname
-‐L
=
list
SPNs
registered
to
target
account
Usage:
setspn
[-‐L]
accountname
Edit
Mode
Modifiers
-‐C
=
specify
that
accountname
is
a
computer
account
Log Breakdown
• KDC
host
info
not
initialized,
attempting
to
initialize–
KDC
host
information
is
being
initialized.
• acquiring
GSS-‐TSIG
credentials–
Acquire
DHCP
server
credentials
• acquired
GSS-‐TSIG
credentials
–
DHCP
Server
credentials
acquired
• GSS-‐TSIG
security
context
for
server
–
GSS-‐TSIG
security
context
initialization
checks
continue
• GSS-‐TSIG
security
context
state
for
server
–
Security
context
state
is
checked.
If
checks
on
SOA
and
MNAME
found
the
security
context
state
is
marked
OK
• service
principal
DNS/windows-‐dc.W00T.COM@W00T.COM-‐
This
is
the
Windows
DNS
SPN
• initializing/negotiating
GSS-‐TSIG
security
context
with
requested
lifetime
of
7200
seconds
–
GSS-‐TSIG
security
context
is
initialized
and
requested
lifetime
of
2
hour
(7200
sec.)
requested.
• GSS-‐TSIG
security
context
negotiation
completed;
context
will
be
valid
for
7209
seconds–A
valid
security
context
has
been
created
and
is
ready
for
use.
Security
context
is
now
saved
by
DNS
server
and
DHCP
server
(DNS
Client).
• TSIG(GSSTSIG)
verification
success–
TSIG
Key
now
obtained
from
valid
Security
Context
DDNS
updates
can
now
proceed.
You
will
now
see
this
message
before
DDNS
updates
are
completed.
• added
new
forward
map–
from
hostname.domain.com
to
x.x.x.x
(standard
DDNS
forward
map)
• added
reverse
map
–
from
x.x.x.x.in-‐addr.arpa
to
hostname.domain.com
(standard
DDNS
reverse
map)
Troubleshooting
When
you
begin
troubleshooting
a
Kerberos
problem
and
you
are
certain
that
the
configuration
is
correct,
there
are
a
few
common
trouble
spots
that
you
should
check
first:
• Clock
skew
• Encryption
types
• Key
tables
• Domain/realm
mapping
• Name
resolution
• Firewall
Note:
Additional
troubleshooting
information
can
also
be
found
on
CARE
in
KB-‐2956
Clock Skew
Time
differences
are
a
common
factor
when
dealing
with
Kerberos
configuration.
Kerberos
requires
that
all
the
computers
in
the
environment
have
system
times
within
5
minutes
of
one
another.
If
computers
that
a
client
is
attempting
to
use
for
either
initial
authentication
(the
Kerberos
server)
or
resource
access
(including
both
the
application
server
and,
in
a
cross-‐realm
environment,
an
alternate
Kerberos
server)
have
a
delta
greater
than
5
minutes
from
the
client
computer
or
from
one
another,
the
Kerberos
authentication
will
fail.
Time
synchronization
problems
can
be
identified
when
an
error
similar
to
“Clock
skew
too
great”
is
returned,
although
other
more
obscure
errors
may
also
indicate
time
synchronization
problems.
Windows-‐based
computers
may
generate
Event
ID
11
from
w32time
in
their
event
log
if
the
computer
is
having
trouble
synchronizing
its
time.
• Basic
time
syncing.
Is
each
computer
in
the
environment
within
5
minutes
of
all
the
others?
Note
that
an
environment
where
the
client
is
3
minutes
slower
than
the
Kerberos
server
and
the
application
server
is
3
minutes
faster
than
the
Kerberos
server
represents
a
time
syncing
problem,
as
the
total
skew
is
6
minutes.
• Time
zone
inconsistencies.
Clocks
may
appear
to
be
in
sync
and
still
create
problems
if
time
zones
on
either
computer
are
not
set
correctly.
On
UNIX-‐based
computers
the
date
-‐u
command
can
be
used
to
check
the
absolute
time
of
each
computer.
Encryption Types
Each
Kerberos
implementation
supports
a
set
of
encryption
types
used
to
encrypt
part
of
the
Kerberos
traffic.
The
set
of
supported
encryption
types
varies
slightly
by
implementation,
so
in
building
a
heterogeneous
environment
encryption
types
that
are
supported
for
all
involved
implementations
must
be
selected.
For
example,
Active
Directory®
directory
service
supports
the
RC4-‐HMAC
encryption
type,
but
native
UNIX
and
older
MIT
implementations
do
not.
Many
UNIX
implementations
support
the
SHA1
encryption
type,
but
Active
Directory
does
not
(except
with
Windows
2008
and
2008
R2).
Most
implementations
support
DES-‐CRC
and
DES-‐MD5.
Although
these
encryption
types
are
not
as
secure
as
RC4-‐HMAC
and
SHA1.
Note:
Proteus
and
Adonis
currently
support
the
following
encryption
types:
• AES-‐128
CTS
mode
with
96-‐bit
SHA1
HMAC
(only
for
Windows
2008
server
and
2008
R2)
• AES-‐256
CTS
mode
with
96-‐bit
SHA1
HMAC
(only
for
Windows
2008
server
and
2008
R2)
• ArcFour
with
HMAC/md5
• Triple
DES
cbc
mode
with
HMAC/sha1
• DES
cbc
mode
with
RSA-‐MD5
• DES
cbc
mode
with
CRC-‐32
Note:
To
add
the
AES256
encryption
type,
you
will
need
to
download
the
Java
Cryptography
Extension
(JCE)
Unlimited
Strength
Jurisdiction
Policy
Files
6
from:
http://www.oracle.com/technetwork/java/javase/downloads/jce-‐6-‐download-‐429243.html
After
you
download
jce_policy_6.zip
file
from
the
above
URL,
uncompress
and
extract
the
downloaded
files
on
your
local
system.
Then
follow
the
steps
below:
1. SCP
the
two
files
located
in
the
JCE
folder
(local_policy.jar
and
US_export_policy.jar)
to
the
/root
folder
on
Adonis.
2. Locate
the
following
two
JAR
files
(local_policy.jar
and
US_export_policy.jar)
on
Adonis
server
by
running
the
following
command
as
root:
Key
Tables
In
a
Kerberos
environment,
both
a
client
(a
user)
and
a
server
(the
server
side
component
of
an
application)
must
have
a
key
(a
password).
On
an
application
server,
this
key
is
stored
in
a
key
table
(by
default
a
krb5.keytab
file).
If
the
key
stored
in
the
key
table
on
the
application
server
does
not
match
the
key
for
this
service
stored
in
the
Kerberos
database,
or
if
the
application
does
not
have
access
to
read
the
key
from
the
table,
the
application
will
not
be
capable
of
completing
its
side
of
the
Kerberos
transaction.
Domain/REALM Mapping
To
access
Kerberized
services,
the
client
computer
must
be
capable
of
resolving
the
DNS
domain
of
the
target
computer
to
the
correct
Kerberos
REALM.
This
becomes
an
issue
when
the
DNS
domain
name
does
not
match
the
Kerberos
REALM
name.
Because
mapping
does
not
become
an
issue
until
the
client
computer
tries
to
access
a
service,
domain
to
REALM
mapping
problems
do
not
affect
initial
ticket
requests
(TGTs).
When
mapping
problems
exist,
service
ticket
requests
may
fail
or
access
to
Kerberized
services
may
fail.
With
Active
Directory,
the
REALM
name
is
always
the
uppercase
equivalent
of
the
DNS
domain
name.
Name Resolution
Problems
with
Kerberos
are
often
related
to
name
resolution
or
Domain
Name
System
(DNS)
problems.
Active
Directory
domain
controllers,
Windows
clients,
UNIX
clients,
and
application
servers
must
all
have
a
shared
understanding
of
the
correct
host
names
and
IP
addresses
for
each
computer
within
the
environment.
DNS
is
the
typical
way
of
computers
doing
name
resolution;
however,
this
might
be
combined
with
hosts
filesor
other
means.
DNS
will
be
the
focus
of
this
section.
Configuration
problems
with
DNS
can
be
subtle
but
still
affect
the
functionality
of
Kerberos.
Investigate DNS issues if you are experiencing error messages similar to those listed as follows:
• DNS
problems
are
often
encountered
only
during
a
service
ticket
request
after
a
successful
TGT
request.
If
a
client
can
successfully
authenticate
initially
but
is
then
unable
to
acquire
a
service
ticket
or
access
services,
then
DNS
problems
are
the
likely
cause.
• The
error
“Server
not
found
in
Kerberos
database”
is
common
and
can
be
misleading
because
it
often
appears
when
the
service
principal
is
not
missing.
The
error
can
be
caused
by
domain/realm
mapping
problems
or
it
can
be
the
result
of
a
DNS
problem
where
the
service
principal
name
is
not
being
built
correctly.
Server
logs
and
network
traces
can
be
used
to
determine
what
service
principal
is
actually
being
requested.
• Kerberos
is
case
sensitive.
Problems
can
occur
in
an
environment
using
host
names
with
mixed
case.
In
the
world
of
Kerberos,
appserver1.EXAMPLE.COM
and
appserver1.example.com
are
not
the
same.
Check
that
DNS
resolves
host
names
with
consistent
case.
• Kerberos
relies
on
the
presence
of
both
forward
and
reverse
lookup
entries
in
DNS.
Check
that
the
host
name
of
each
computer
can
be
resolved
to
its
IP
address
and
that
its
IP
address
can
be
resolved
to
its
host
name.
• Look
carefully
at
the
configuration
of
any
multihomed
hosts.
You
might
need
to
perform
network
traces
to
determine
which
interfaces
and
what
names
are
being
used
in
requests
to
or
from
computers
with
multiple
network
cards.
Firewall
Firewall
systems
can
cause
many
different
error
messages
to
be
misleading
or
non-‐existent.
On
Windows
based
systems
running
firewall
services,
you
must
make
sure
Port
53
(UDP
/
TCP)
and
Port
88
(TCP
/
UDP)
are
open
to
reduce
the
problems
with
GSS-‐TSIG
(using
Option
#1
as
specified
on
page
5).
Note:
You
can
verify
if
connection
issues
is
on
Adonis
side
by
running
the
following
TCPDump
command:
Normal output
Blocked output
21:00:41.464628
IP
(tos
0x0,
ttl
64,
id
13790,
offset
0,
flags
[DF],
proto
TCP
(6),
length
60)
172.21.12.110.36378
>
172.21.12.115.88:
S,
cksum
0x713a
(incorrect
(-‐>
0xbac1),
3060986958:3060986958(0)
win
5840
<mss
1460,sackOK,timestamp
178241936
0,nop,wscale
6>
21:00:44.467100
IP
(tos
0x0,
ttl
64,
id
49303,
offset
0,
flags
[DF],
proto
UDP
(17),
length
207)
172.21.12.110.37773
>
172.21.12.115.88:
[udp
sum
ok]
v5
21:00:44.469582
IP
(tos
0x0,
ttl
64,
id
13791,
offset
0,
flags
[DF],
proto
TCP
(6),
length
60)
172.21.12.110.36378
>
172.21.12.115.88:
S,
cksum
0x713a
(incorrect
(-‐>
0xb7d1),
3060986958:3060986958(0)
win
5840
<mss
1460,sackOK,timestamp
178242688
0,nop,wscale
6>
21:00:49.471356
IP
(tos
0x0,
ttl
64,
id
49304,
offset
0,
flags
[DF],
proto
UDP
(17),
length
207)
172.21.12.110.37773
>
172.21.12.115.88:
[udp
sum
ok]
v5
21:00:50.485600
IP
(tos
0x0,
ttl
64,
id
13792,
offset
0,
flags
[DF],
proto
TCP
(6),
length
60)
172.21.12.110.36378
>
172.21.12.115.88:
S,
cksum
0x713a
(incorrect
(-‐>
0xb1f1),
3060986958:3060986958(0)
win
5840
<mss
1460,sackOK,timestamp
178244192
0,nop,wscale
6>
Note: On Window Server in Event Viewer -‐> Security look for Event ID = 4768
Normal output
Account Information:
Service Information:
Network
Information:
Client
Address:
172.21.12.110
Client
Port:
41192
Additional
Information:
Ticket
Options:
0x10
Result
Code:
0x0
Ticket
Encryption
Type:
0x17
Pre-‐Authentication
Type:
2
kinit(v5):
Clients
credentials
have
been
revoked
while
getting
initial
credentials.
Active
Directory
user
account
is
disabled
or
locked.
Check
if
the
AD
user
account
is
enabled.
kinit(v5):
Cannot
contact
any
KDC
for
realm
‘EXAMPLE.COM’
while
getting
initial
credentials.
KDC
server
is
not
available.
Several
network
or
service-‐related
issues
can
be
at
the
origin
of
this
message,
including
network
disruption,
incorrect
IP
configuration
for
the
KDC
server,
or
temporary
KDC
serviceinterruption.
Verify
both
server
availability
and
network
connectivity
and
verify
if
the
Kerberos
realm
name
and
KDC
IP
addresses
configured
in
Proteus
are
correct.
kinit(v5):
Cannot
find
KDC
for
requested
realm
while
getting
initial
credentials
This
error
is
caused
by
specifying
the
wrong
Kerberos
realm
name.
Verify
that
you
have
entered
the
correct
Kerberos
realm
name
in
Proteus.
kinit(v5):
Client
not
found
in
Kerberos
database
while
getting
initial
credentials
You
have
specified
an
incorrect
DHCP
service
principal
name
in
Proteus.
Check
the
service
principal
name
matches
the
name
in
Active
Directory.
Note:
You
may
also
see
this
error
following
periods
of
high
DDNS
traffic
when
AD
synchronization
is
running
with
Kerberos
and
DNS
on
the
same
server.
In
the
DNS
events
log,
we
can
see
“Event
ID:
4013
The
DNS
server
is
waiting
for
Active
Directory
Domain
Services
(AD
DS)
to
signal
that
the
initial
synchronization
of
the
directory
has
been
completed.
The
DNS
server
service
cannot
start
until
the
initial
synchronization
is
complete
because
critical
DNS
data
might
not
yet
be
replicated
onto
this
domain
controller.
If
events
in
the
AD
DS
event
log
indicate
that
there
is
a
problem
with
DNS
name
resolution,
consider
adding
the
IP
address
of
another
DNS
server
for
this
domain
to
the
DNS
server
list
in
the
Internet
Protocol
properties
of
this
computer.
This
event
will
be
logged
every
two
minutes
until
AD
DS
has
signaled
that
the
initial
synchronization
has
successfully
completed.”
Example of an entry in syslog where the server is found to be alive:
Jul
23
13:59:19
adonis1
dhcpd:
Server
172.21.12.115
is
NOT
alive
Example
of
syslog
with
entire
found
to
be
alive
process:
Jul
23
13:59:19
adonis1
dhcpd:
GSS-‐TSIG
security
context
for
server
172.21.12.115
is
new
or
marked
for
retry,
checking
if
server
is
alive...
Jul
23
13:59:19
adonis1
dhcpd:
ns_lookup
function
for
W00T.COM
with
type
6
Jul
23
13:59:19
adonis1
dhcpd:
addr=172.21.12.115
Jul
23
13:59:19
adonis1
dhcpd:
ns_lookup:
answer
returned
0
Jul
23
13:59:19
adonis1
dhcpd:
Found
SOA
name=W00T.COM
rdatalength=46
Jul
23
13:59:19
adonis1
dhcpd:
Found
MNAME
name=windows-‐dc.W00T.COM
Jul
23
13:59:19
adonis1
dhcpd:
Server
172.21.12.115
is
alive;
mname=windows-‐dc.W00T.COM
Note:
By
default,
a
Kerberos
client
(i.e.
the
Adonis
DHCP
server
when
GSS-‐TSIG
is
deployed
for
Adonis
DHCP
to
update
Microsoft
Windows
DNS)
initially
tries
to
send
a
request
over
UDP
during
the
Kerberos
negotiation
process.
The
server
proceeds
with
preparing
the
response
and
attempting
to
send
it
over
UDP.
If
the
response
is
too
large
to
be
sent
over
UDP,
the
Kerberos
client
automatically
switches
to
TCP.
Although
this
process
represents
normal
behavior,
you
may
experience
slower
response
time
for
that
request.
If
TCP
is
preferred
for
the
initial
request,
it
can
be
configured
on
both
the
DNS
and
DHCP
server
side.
To
force
Windows
to
always
use
TCP,
follow
the
instructions
described
in
the
following
article:
http://support.microsoft.com/kb/244474