On Mon, Feb 13, 2017 at 12:48 PM, Michael Hirmke <mh@mike.franken.de> wrote:
Hi Roger,
They did differ in one line:
[domain_realm] .ramse.ramboll-group.global.network = RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK .ramboll.ramboll-group.global.network = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK
The working samba had the line that starts with .ramse. The non-working did not. .ramse is an old domain. It is now .ramboll.
I added that line to the new server (a restarted smb and nmb) but it made no difference.
no this difference couldn't be the reason for your problem. What about the lines for encryption types? What about the [libdefaults] section? Can you post them, please?
This is the entire file (as made by Yast): [libdefaults] default_realm = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK clockskew = 300 # default_realm = EXAMPLE.COM [realms] RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK = { kdc = ramstodc02.ramboll.ramboll-group.global.network default_domain = ramboll.ramboll-group.global.network admin_server = ramstodc02.ramboll.ramboll-group.global.network } RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK = { kdc = seramstodc04.ramse.ramboll-group.global.network default_domain = ramse.ramboll-group.global.network admin_server = seramstodc04.ramse.ramboll-group.global.network } # EXAMPLE.COM = { # kdc = kerberos.example.com # admin_server = kerberos.example.com # } [logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON [domain_realm] .ramse.ramboll-group.global.network = RAMSE.RAMBOLL-GROUP.GLOBAL.NETWORK .ramboll.ramboll-group.global.network = RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false minimum_uid = 1 } It seems not to have: [libdefaults] dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes
As someone else wrote, there are differences (and not only a few) between the two samba and the two kerberos versions on your different systems.
A very simple krb5.conf for two different AD *forests* may look like this:
------------------------< snip snip snip >----------------------------- [logging] default = FILE:/var/log/krb5/libs.log kdc = FILE:/var/log/krb5/kdc.log admin_server = FILE:/var/log/krb5/kadmind.log
[libdefaults] default_realm = DOMAIN1.DE dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes
[realms] DOMAIN1.DE = { kdc = dc1.domain1.de kdc = dc2.domain1.de admin_server = dc1.domain1.de default_domain = domain1.de } DOMAIN2.DE = { kdc = dc1.domain2.de kdc = dc2.domain2.de admin_server = dc1.domain2.de default_domain = domain2.de }
[domain_realm] .domain1.de = DOMAIN1.DE domain1.de = DOMAIN1.DE .domain2.de = DOMAIN2.DE domain2.de = DOMAIN2.DE ------------------------< snip snip snip >-----------------------------
This works perfectly here with the latest samba and kerberos versions for openSuSE Leap 42.2 and Tumbleweed against an AD with forest and domain functional level set to "Windows Server 2012 R2".
I see that there is a reference to a couple of log files:
[logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON
These files do not exist. The /var/log/krb5 directory is empty.
They are not used for samba's purpose, only if you use a native Kerberos server.
What happens, if you run "kinit <someuser>". Do you get a password prompt? And if you enter the password, do you get a ticket (klist)?
When I tried a user from the domain, it seems it was ok. There was no complaint: sto-opq-src:~ # kinit roropq Password for roropq@RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK: sto-opq-src:~ # When I tried a non-existent user, I got: sto-opq-src:~ # kinit roger kinit: Client 'roger@RAMBOLL.RAMBOLL-GROUP.GLOBAL.NETWORK' not found in Kerberos database while getting initial credentials sto-opq-src:~ # So if this is a test of the Kerberos part, it seems to be working. smbclient, otoh, made the same complaint (as does Windows about an access error): sto-opq-src:~ # smbclient --user=roropq //localhost/roger WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_ACCESS_DENIED sto-opq-src:~ # It I try a share that does not exist, I get: sto-opq-src:~ # smbclient --user=roropq //localhost/rog WARNING: The "idmap gid" option is deprecated WARNING: The "idmap uid" option is deprecated Domain=[RAMBOLL] OS=[Windows 6.1] Server=[Samba 4.5.3-0-SUSE-oS13.3-x86_64] tree connect failed: NT_STATUS_BAD_NETWORK_NAME sto-opq-src:~ # So the share is known on localhost... Does all this imply that kerberos on my machine is ok, but that samba is the problem? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org