Kerberos: cannot propagate database between linux master and slave kdc'sHow to Change the Kerberos Default...

How to preserve electronics (computers, ipads, phones) for hundreds of years?

What should be the ideal length of sentences in a blog post for ease of reading?

Magnifying glass in hyperbolic space

Why would five hundred and five same as one?

Does capillary rise violate hydrostatic paradox?

is this saw blade faulty?

Relations between homogeneous polynomials

Would this string work as string?

Why is participating in the European Parliamentary elections used as a threat?

Why didn't Voldemort know what Grindelwald looked like?

What is the meaning of "You've never met a graph you didn't like?"

Weird lines in Microsoft Word

Recursively move files within sub directories

Why doesn't Gödel's incompleteness theorem apply to false statements?

Hashing password to increase entropy

Checking @@ROWCOUNT failing

Offset in split text content

"Oh no!" in Latin

How can a new country break out from a developed country without war?

What (if any) is the reason to buy in small local stores?

Why do Radio Buttons not fill the entire outer circle?

1 John in Luther’s Bibel

What is the purpose of using a decision tree?

How would a solely written language work mechanically



Kerberos: cannot propagate database between linux master and slave kdc's


How to Change the Kerberos Default Ticket Lifetimehelp using setspn and ktpassWrong principal in request (SSH/ GSSAPI/Kerberos/Debian)Kerberos setup on Red HatHow to reset Keytab for FreeIPA Server and ClientConfiguring ENUM on BIND 9.8.1Squid with AD groups + Kerberos authentication in pfsense?Samba/Kerberos: Cannot contact any KDC, Kerberos not listening?Samba ADS: Cannot contact any KDC for requested realmConfiguration NFS v3 Kerberos on Centos 5.x













0















The command



sudo kprop -r MY.DOMAIN -f /var/lib/krb5kdc/slave_datatrans slave_kdc.my.domain


returns



kprop: Key table entry not found while getting initial credentials


This is a new installation on two linux debian servers. The master_kdc seems to work, but I cannot get the database to propagate. I manually copied the database dump and loaded it onto the slave_kdc, but the propagation still does not work.



/etc/krb5.conf



[libdefaults]
default_realm = MY.DOMAIN
# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

[realms]
MY.DOMAIN = {
kdc = master_kdc.my.domain
kdc = slave_kdc.my.domain
admin_server = master_kdc.my.domain
}
[domain_realm]
.my.domain = MY.DOMAIN
my.domain = MY.DOMAIN


/etc/krb5kdc/kdc.conf



[kdcdefaults]
kdc_ports = 750,88

[realms]
MY.DOMAIN = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
#supported_enctypes = aes256-cts:normal aes128-cts:normal
default_principal_flags = +preauth
}

[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log


/etc/krb6kdc/kadm5/acl



john/admin@MY.DOMAIN        *


/etc/krb5kdc/kpropd.acl



host/master_kdc.my.domain@MY.DOMAIN
host/slave_kdc.my.domain@MY.DOMAIN


I installed xinetd and created the following file and enabled and started the xinetd service.
/etc/xinetd.d/krb5_prop



service krb5_prop
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/kpropd
}


result of sudo cat /etc/services | grep krb5



kerberos    88/tcp      kerberos5 krb5 kerberos-sec # Kerberos v5
kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5
krb5_prop 754/tcp krb-prop krb_prop hprop # Kerberos slave propagation


I generated the /etc/krb5.keytab file on master_kdc and on slave_kdc after copying over the database.



kadmin: ktadd host/slave_kdc.my.domain


Nothing is being logged (I don't know why).



/etc/bind/zones/db.my.domain



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.

; Name servers - A records
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Kerberos services
_kerberos._udp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._udp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos-adm._tcp.MY.DOMAIN. IN SRV 1 0 749 master_kdc.my.domain.
_kpasswd._udp.MY.DOMAIN. IN SRV 1 0 464 master_kdc.my.domain.


/etc/bind/zones/db.AAA



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Name servers - PTR records
DD1 IN PTR master_kdc.my.domain.
DD2 IN PTR slave_kdc.my.domain.









share|improve this question




















  • 1





    In your description I am missing the part were the keytabs are created and deployed. The file /etc/krb5kdc/kpropd.acl can have just one entry host/master_kdc.my.domain@MY.DOMAIN. Yes, you should get rid of the extra realms in /etc/krb5.conf. The file /etc/xinetd.d/krb5_prop should also contain an entry about the IP address of the service. In my config the service has the same name in /etc/services as /etc/xinetd.d/krb5_prop.

    – U880D
    Apr 27 '18 at 6:01











  • @U880D I edited the question to reflect light modifications and added a bit about generating the keytabs. I don't know what format to add the IP address to the xinetd.d/krb5_prop.

    – Paul B
    Apr 30 '18 at 15:59






  • 1





    During my setup I've experienced the same problem and learned that DNS is very important. For all hosts hostnames, FQDNs and PTRs were necessary. The dig and host command showed the rights entries for all involved nodes. The stash file was also important, I had to check my passwords. I'll try to check my notes for a more detailed description and/or step-by-step instructions.

    – U880D
    Apr 30 '18 at 16:13
















0















The command



sudo kprop -r MY.DOMAIN -f /var/lib/krb5kdc/slave_datatrans slave_kdc.my.domain


returns



kprop: Key table entry not found while getting initial credentials


This is a new installation on two linux debian servers. The master_kdc seems to work, but I cannot get the database to propagate. I manually copied the database dump and loaded it onto the slave_kdc, but the propagation still does not work.



/etc/krb5.conf



[libdefaults]
default_realm = MY.DOMAIN
# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

[realms]
MY.DOMAIN = {
kdc = master_kdc.my.domain
kdc = slave_kdc.my.domain
admin_server = master_kdc.my.domain
}
[domain_realm]
.my.domain = MY.DOMAIN
my.domain = MY.DOMAIN


/etc/krb5kdc/kdc.conf



[kdcdefaults]
kdc_ports = 750,88

[realms]
MY.DOMAIN = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
#supported_enctypes = aes256-cts:normal aes128-cts:normal
default_principal_flags = +preauth
}

[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log


/etc/krb6kdc/kadm5/acl



john/admin@MY.DOMAIN        *


/etc/krb5kdc/kpropd.acl



host/master_kdc.my.domain@MY.DOMAIN
host/slave_kdc.my.domain@MY.DOMAIN


I installed xinetd and created the following file and enabled and started the xinetd service.
/etc/xinetd.d/krb5_prop



service krb5_prop
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/kpropd
}


result of sudo cat /etc/services | grep krb5



kerberos    88/tcp      kerberos5 krb5 kerberos-sec # Kerberos v5
kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5
krb5_prop 754/tcp krb-prop krb_prop hprop # Kerberos slave propagation


I generated the /etc/krb5.keytab file on master_kdc and on slave_kdc after copying over the database.



kadmin: ktadd host/slave_kdc.my.domain


Nothing is being logged (I don't know why).



/etc/bind/zones/db.my.domain



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.

; Name servers - A records
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Kerberos services
_kerberos._udp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._udp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos-adm._tcp.MY.DOMAIN. IN SRV 1 0 749 master_kdc.my.domain.
_kpasswd._udp.MY.DOMAIN. IN SRV 1 0 464 master_kdc.my.domain.


/etc/bind/zones/db.AAA



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Name servers - PTR records
DD1 IN PTR master_kdc.my.domain.
DD2 IN PTR slave_kdc.my.domain.









share|improve this question




















  • 1





    In your description I am missing the part were the keytabs are created and deployed. The file /etc/krb5kdc/kpropd.acl can have just one entry host/master_kdc.my.domain@MY.DOMAIN. Yes, you should get rid of the extra realms in /etc/krb5.conf. The file /etc/xinetd.d/krb5_prop should also contain an entry about the IP address of the service. In my config the service has the same name in /etc/services as /etc/xinetd.d/krb5_prop.

    – U880D
    Apr 27 '18 at 6:01











  • @U880D I edited the question to reflect light modifications and added a bit about generating the keytabs. I don't know what format to add the IP address to the xinetd.d/krb5_prop.

    – Paul B
    Apr 30 '18 at 15:59






  • 1





    During my setup I've experienced the same problem and learned that DNS is very important. For all hosts hostnames, FQDNs and PTRs were necessary. The dig and host command showed the rights entries for all involved nodes. The stash file was also important, I had to check my passwords. I'll try to check my notes for a more detailed description and/or step-by-step instructions.

    – U880D
    Apr 30 '18 at 16:13














0












0








0








The command



sudo kprop -r MY.DOMAIN -f /var/lib/krb5kdc/slave_datatrans slave_kdc.my.domain


returns



kprop: Key table entry not found while getting initial credentials


This is a new installation on two linux debian servers. The master_kdc seems to work, but I cannot get the database to propagate. I manually copied the database dump and loaded it onto the slave_kdc, but the propagation still does not work.



/etc/krb5.conf



[libdefaults]
default_realm = MY.DOMAIN
# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

[realms]
MY.DOMAIN = {
kdc = master_kdc.my.domain
kdc = slave_kdc.my.domain
admin_server = master_kdc.my.domain
}
[domain_realm]
.my.domain = MY.DOMAIN
my.domain = MY.DOMAIN


/etc/krb5kdc/kdc.conf



[kdcdefaults]
kdc_ports = 750,88

[realms]
MY.DOMAIN = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
#supported_enctypes = aes256-cts:normal aes128-cts:normal
default_principal_flags = +preauth
}

[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log


/etc/krb6kdc/kadm5/acl



john/admin@MY.DOMAIN        *


/etc/krb5kdc/kpropd.acl



host/master_kdc.my.domain@MY.DOMAIN
host/slave_kdc.my.domain@MY.DOMAIN


I installed xinetd and created the following file and enabled and started the xinetd service.
/etc/xinetd.d/krb5_prop



service krb5_prop
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/kpropd
}


result of sudo cat /etc/services | grep krb5



kerberos    88/tcp      kerberos5 krb5 kerberos-sec # Kerberos v5
kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5
krb5_prop 754/tcp krb-prop krb_prop hprop # Kerberos slave propagation


I generated the /etc/krb5.keytab file on master_kdc and on slave_kdc after copying over the database.



kadmin: ktadd host/slave_kdc.my.domain


Nothing is being logged (I don't know why).



/etc/bind/zones/db.my.domain



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.

; Name servers - A records
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Kerberos services
_kerberos._udp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._udp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos-adm._tcp.MY.DOMAIN. IN SRV 1 0 749 master_kdc.my.domain.
_kpasswd._udp.MY.DOMAIN. IN SRV 1 0 464 master_kdc.my.domain.


/etc/bind/zones/db.AAA



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Name servers - PTR records
DD1 IN PTR master_kdc.my.domain.
DD2 IN PTR slave_kdc.my.domain.









share|improve this question
















The command



sudo kprop -r MY.DOMAIN -f /var/lib/krb5kdc/slave_datatrans slave_kdc.my.domain


returns



kprop: Key table entry not found while getting initial credentials


This is a new installation on two linux debian servers. The master_kdc seems to work, but I cannot get the database to propagate. I manually copied the database dump and loaded it onto the slave_kdc, but the propagation still does not work.



/etc/krb5.conf



[libdefaults]
default_realm = MY.DOMAIN
# The following krb5.conf variables are only for MIT Kerberos.
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

[realms]
MY.DOMAIN = {
kdc = master_kdc.my.domain
kdc = slave_kdc.my.domain
admin_server = master_kdc.my.domain
}
[domain_realm]
.my.domain = MY.DOMAIN
my.domain = MY.DOMAIN


/etc/krb5kdc/kdc.conf



[kdcdefaults]
kdc_ports = 750,88

[realms]
MY.DOMAIN = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
#supported_enctypes = aes256-cts:normal aes128-cts:normal
default_principal_flags = +preauth
}

[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log


/etc/krb6kdc/kadm5/acl



john/admin@MY.DOMAIN        *


/etc/krb5kdc/kpropd.acl



host/master_kdc.my.domain@MY.DOMAIN
host/slave_kdc.my.domain@MY.DOMAIN


I installed xinetd and created the following file and enabled and started the xinetd service.
/etc/xinetd.d/krb5_prop



service krb5_prop
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/kpropd
}


result of sudo cat /etc/services | grep krb5



kerberos    88/tcp      kerberos5 krb5 kerberos-sec # Kerberos v5
kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5
krb5_prop 754/tcp krb-prop krb_prop hprop # Kerberos slave propagation


I generated the /etc/krb5.keytab file on master_kdc and on slave_kdc after copying over the database.



kadmin: ktadd host/slave_kdc.my.domain


Nothing is being logged (I don't know why).



/etc/bind/zones/db.my.domain



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.

; Name servers - A records
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Kerberos services
_kerberos._udp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 1 0 88 master_kdc.my.domain.
_kerberos._udp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos._tcp.MY.DOMAIN. IN SRV 10 0 88 slave_kdc.my.domain.
_kerberos-adm._tcp.MY.DOMAIN. IN SRV 1 0 749 master_kdc.my.domain.
_kpasswd._udp.MY.DOMAIN. IN SRV 1 0 464 master_kdc.my.domain.


/etc/bind/zones/db.AAA



$TTL    604800
@ IN SOA master_kdc.my.domain. john.my.domain. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; Name servers - NS records
@ IN NS master_kdc.my.domain.
@ IN NS slave_kdc.my.domain.
master_kdc IN A AAA.BBB.CCC.DD1
slave_kdc IN A AAA.BBB.CCC.DD2

; Name servers - PTR records
DD1 IN PTR master_kdc.my.domain.
DD2 IN PTR slave_kdc.my.domain.






linux kerberos






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited May 1 '18 at 13:04







Paul B

















asked Apr 21 '18 at 0:30









Paul BPaul B

11




11








  • 1





    In your description I am missing the part were the keytabs are created and deployed. The file /etc/krb5kdc/kpropd.acl can have just one entry host/master_kdc.my.domain@MY.DOMAIN. Yes, you should get rid of the extra realms in /etc/krb5.conf. The file /etc/xinetd.d/krb5_prop should also contain an entry about the IP address of the service. In my config the service has the same name in /etc/services as /etc/xinetd.d/krb5_prop.

    – U880D
    Apr 27 '18 at 6:01











  • @U880D I edited the question to reflect light modifications and added a bit about generating the keytabs. I don't know what format to add the IP address to the xinetd.d/krb5_prop.

    – Paul B
    Apr 30 '18 at 15:59






  • 1





    During my setup I've experienced the same problem and learned that DNS is very important. For all hosts hostnames, FQDNs and PTRs were necessary. The dig and host command showed the rights entries for all involved nodes. The stash file was also important, I had to check my passwords. I'll try to check my notes for a more detailed description and/or step-by-step instructions.

    – U880D
    Apr 30 '18 at 16:13














  • 1





    In your description I am missing the part were the keytabs are created and deployed. The file /etc/krb5kdc/kpropd.acl can have just one entry host/master_kdc.my.domain@MY.DOMAIN. Yes, you should get rid of the extra realms in /etc/krb5.conf. The file /etc/xinetd.d/krb5_prop should also contain an entry about the IP address of the service. In my config the service has the same name in /etc/services as /etc/xinetd.d/krb5_prop.

    – U880D
    Apr 27 '18 at 6:01











  • @U880D I edited the question to reflect light modifications and added a bit about generating the keytabs. I don't know what format to add the IP address to the xinetd.d/krb5_prop.

    – Paul B
    Apr 30 '18 at 15:59






  • 1





    During my setup I've experienced the same problem and learned that DNS is very important. For all hosts hostnames, FQDNs and PTRs were necessary. The dig and host command showed the rights entries for all involved nodes. The stash file was also important, I had to check my passwords. I'll try to check my notes for a more detailed description and/or step-by-step instructions.

    – U880D
    Apr 30 '18 at 16:13








1




1





In your description I am missing the part were the keytabs are created and deployed. The file /etc/krb5kdc/kpropd.acl can have just one entry host/master_kdc.my.domain@MY.DOMAIN. Yes, you should get rid of the extra realms in /etc/krb5.conf. The file /etc/xinetd.d/krb5_prop should also contain an entry about the IP address of the service. In my config the service has the same name in /etc/services as /etc/xinetd.d/krb5_prop.

– U880D
Apr 27 '18 at 6:01





In your description I am missing the part were the keytabs are created and deployed. The file /etc/krb5kdc/kpropd.acl can have just one entry host/master_kdc.my.domain@MY.DOMAIN. Yes, you should get rid of the extra realms in /etc/krb5.conf. The file /etc/xinetd.d/krb5_prop should also contain an entry about the IP address of the service. In my config the service has the same name in /etc/services as /etc/xinetd.d/krb5_prop.

– U880D
Apr 27 '18 at 6:01













@U880D I edited the question to reflect light modifications and added a bit about generating the keytabs. I don't know what format to add the IP address to the xinetd.d/krb5_prop.

– Paul B
Apr 30 '18 at 15:59





@U880D I edited the question to reflect light modifications and added a bit about generating the keytabs. I don't know what format to add the IP address to the xinetd.d/krb5_prop.

– Paul B
Apr 30 '18 at 15:59




1




1





During my setup I've experienced the same problem and learned that DNS is very important. For all hosts hostnames, FQDNs and PTRs were necessary. The dig and host command showed the rights entries for all involved nodes. The stash file was also important, I had to check my passwords. I'll try to check my notes for a more detailed description and/or step-by-step instructions.

– U880D
Apr 30 '18 at 16:13





During my setup I've experienced the same problem and learned that DNS is very important. For all hosts hostnames, FQDNs and PTRs were necessary. The dig and host command showed the rights entries for all involved nodes. The stash file was also important, I had to check my passwords. I'll try to check my notes for a more detailed description and/or step-by-step instructions.

– U880D
Apr 30 '18 at 16:13










1 Answer
1






active

oldest

votes


















0














I spent few hours to resolve this exact same issue.
Finally it was solved by this steps:




  1. create master host principal " addprinc host/mastr.comain.com "

  2. On master server, add to keytab the master host principal " ktadd
    host/mastr.comain.com"


Apparently kprop use "kinit -k" to get a ticket and this only work when you have your master host entry in keytab.






share|improve this answer























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "2"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f908790%2fkerberos-cannot-propagate-database-between-linux-master-and-slave-kdcs%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    0














    I spent few hours to resolve this exact same issue.
    Finally it was solved by this steps:




    1. create master host principal " addprinc host/mastr.comain.com "

    2. On master server, add to keytab the master host principal " ktadd
      host/mastr.comain.com"


    Apparently kprop use "kinit -k" to get a ticket and this only work when you have your master host entry in keytab.






    share|improve this answer




























      0














      I spent few hours to resolve this exact same issue.
      Finally it was solved by this steps:




      1. create master host principal " addprinc host/mastr.comain.com "

      2. On master server, add to keytab the master host principal " ktadd
        host/mastr.comain.com"


      Apparently kprop use "kinit -k" to get a ticket and this only work when you have your master host entry in keytab.






      share|improve this answer


























        0












        0








        0







        I spent few hours to resolve this exact same issue.
        Finally it was solved by this steps:




        1. create master host principal " addprinc host/mastr.comain.com "

        2. On master server, add to keytab the master host principal " ktadd
          host/mastr.comain.com"


        Apparently kprop use "kinit -k" to get a ticket and this only work when you have your master host entry in keytab.






        share|improve this answer













        I spent few hours to resolve this exact same issue.
        Finally it was solved by this steps:




        1. create master host principal " addprinc host/mastr.comain.com "

        2. On master server, add to keytab the master host principal " ktadd
          host/mastr.comain.com"


        Apparently kprop use "kinit -k" to get a ticket and this only work when you have your master host entry in keytab.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 11 mins ago









        SoufasSoufas

        161




        161






























            draft saved

            draft discarded




















































            Thanks for contributing an answer to Server Fault!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f908790%2fkerberos-cannot-propagate-database-between-linux-master-and-slave-kdcs%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            117736 Шеррод Примітки | Див. також | Посилання | Навігаційне...

            As a Security Precaution, the user account has been locked The Next CEO of Stack OverflowMS...

            Маріан Котлеба Зміст Життєпис | Політичні погляди |...