thr3ads.net - samba - [Samba] Opensolaris-ish joins but does not seem to be valid [Oct 2017]

If this information is useful, please help other people find it:
Share via:

Rowland Penny

2017-Oct-12 18:52 UTC

[Samba] Opensolaris-ish joins but does not seem to be valid

On Thu, 12 Oct 2017 13:28:40 -0500 (CDT)
Mike Ray <mray at xes-inc.com> wrote:
> ----- On Oct 11, 2017, at 5:56 PM, samba samba at lists.samba.org wrote:
> 
> > ----- On Oct 10, 2017, at 12:02 PM, samba samba at lists.samba.org
> > wrote:
> > 
> >> On Tue, 10 Oct 2017 11:28:09 -0500 (CDT)
> >> Andrew Martin <amartin at xes-inc.com> wrote:
> >> 
> >> 
> > 
> > Rowland-
> > 
> > I've been poking at this more and think the root of the problem is
> > a Kerberos problem.
> > 
> 
> 
> I threw the log level up to 10 in /etc/smb.conf on the domain
> controller and poked around more.
> 
> Below are some pieces of the log:
> 
> 
> 
> 
> 
>   Kerberos: AS-REQ root/hostname.example.com at EXAMPLE.COM from
> ipv4:192.168.0.115:41751 for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
> expr: (&(objectClass=user)(samAccountName=root/hostname.example.com))
> expr:
> (&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
> servicePrincipalName: host/hostname.example.com servicePrincipalName:
> nfs/hostname.example.com servicePrincipalName:
> HTTP/hostname.example.com servicePrincipalName:
> root/hostname.example.com servicePrincipalName:
> cifs/hostname.example.com servicePrincipalName: host/hostname
> Kerberos: No preauth found, returning PREAUTH-REQUIRED --
> root/hostname.example.com at EXAMPLE.COM Kerberos: AS-REQ
> root/hostname.example.com at EXAMPLE.COM from ipv4:192.168.0.115:40299
> for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
> expr: (&(objectClass=user)(samAccountName=root/hostname.example.com))
> expr:
> (&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
> servicePrincipalName: host/hostname.example.com servicePrincipalName:
> nfs/hostname.example.com servicePrincipalName:
> HTTP/hostname.example.com servicePrincipalName:
> root/hostname.example.com servicePrincipalName:
> cifs/hostname.example.com servicePrincipalName: host/hostname
> Kerberos: Looking for PKINIT pa-data --
> root/hostname.example.com at EXAMPLE.COM Kerberos: Looking for ENC-TS
> pa-data -- root/hostname.example.com at EXAMPLE.COM Kerberos: ENC-TS
> Pre-authentication succeeded -- root/hostname.example.com at EXAMPLE.COM
> using arcfour-hmac-md5 Auth: [Kerberos KDC,ENC-TS Pre-authentication]
> user [(null)]\[root/hostname.example.com at EXAMPLE.COM] at [Thu, 12 Oct
> 2017 12:49:54.074861 CDT] with [arcfour-hmac-md5] status
> [NT_STATUS_OK] workstation [(null)] remote host
> [ipv4:192.168.0.115:40299] became [EXAMPLE]\[HOSTNAME$]
> [S-1-5-21-3036147387 -4093410917-1991690103-378605]. local host
> [NULL] authsam_account_ok: Checking SMB password for user
> root/hostname.example.com at EXAMPLE.COM logon_hours_ok: No hours
> restrictions for user root/hostname.example.com at EXAMPLE.COM Kerberos:
> TGS-REQ root/hostname.example.com at EXAMPLE.COM from
> ipv4:192.168.0.115:47146 for ldap/dc9.example.com at EXAMPLE.COM
> [canonicalize] expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
> expr: (&(objectClass=user)(samAccountName=root/hostname.example.com))
> Kerberos: Client no longer in database:
> root/hostname.example.com at EXAMPLE.COM
> 
> 
> 
> 
> 
> 
> As you can see, during the AS-REQ, the DC makes 3 queries for
> specific SPNs and returns positively after finding that last SPN.
> However, on the TGS-REQ, it only searches for 2 of those SPNs. It is
> a mystery to me why "expr:
> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))"
> does not return -- it is not explicitly listed in the
> "servicePrinicipalName" attribute, but since
> "root/hostname.example.com" is and "@EXAMPLE.COM" is
the realm, I
> would think it could figure it out. I'll keep looking into that;
> however, the lack of the last SPN search seems to me to be a bug.
> 
> Any thoughts?
Yes, you shouldn't have a user called 'root' in AD.
'root' is a Unix user and the AD user 'Administrator' should be
mapped
to 'root'

Rowland

Mike Ray

2017-Oct-12 19:14 UTC

head link

[Samba] Opensolaris-ish joins but does not seem to be valid

----- On Oct 12, 2017, at 1:52 PM, samba samba at lists.samba.org wrote:
> On Thu, 12 Oct 2017 13:28:40 -0500 (CDT)
> Mike Ray <mray at xes-inc.com> wrote:
> 
>> ----- On Oct 11, 2017, at 5:56 PM, samba samba at lists.samba.org
wrote:
>> 
>> > ----- On Oct 10, 2017, at 12:02 PM, samba samba at lists.samba.org
>> > wrote:
>> > 
>> >> On Tue, 10 Oct 2017 11:28:09 -0500 (CDT)
>> >> Andrew Martin <amartin at xes-inc.com> wrote:
>> >> 
>> >> 
>> > 
>> > Rowland-
>> > 
>> > I've been poking at this more and think the root of the
problem is
>> > a Kerberos problem.
>> > 
>> 
>> 
>> I threw the log level up to 10 in /etc/smb.conf on the domain
>> controller and poked around more.
>> 
>> Below are some pieces of the log:
>> 
>> 
>> 
>> 
>> 
>>   Kerberos: AS-REQ root/hostname.example.com at EXAMPLE.COM from
>> ipv4:192.168.0.115:41751 for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
>> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>> expr:
>>
(&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
>> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
>> servicePrincipalName: host/hostname.example.com servicePrincipalName:
>> nfs/hostname.example.com servicePrincipalName:
>> HTTP/hostname.example.com servicePrincipalName:
>> root/hostname.example.com servicePrincipalName:
>> cifs/hostname.example.com servicePrincipalName: host/hostname
>> Kerberos: No preauth found, returning PREAUTH-REQUIRED --
>> root/hostname.example.com at EXAMPLE.COM Kerberos: AS-REQ
>> root/hostname.example.com at EXAMPLE.COM from ipv4:192.168.0.115:40299
>> for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
>> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>> expr:
>>
(&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
>> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
>> servicePrincipalName: host/hostname.example.com servicePrincipalName:
>> nfs/hostname.example.com servicePrincipalName:
>> HTTP/hostname.example.com servicePrincipalName:
>> root/hostname.example.com servicePrincipalName:
>> cifs/hostname.example.com servicePrincipalName: host/hostname
>> Kerberos: Looking for PKINIT pa-data --
>> root/hostname.example.com at EXAMPLE.COM Kerberos: Looking for ENC-TS
>> pa-data -- root/hostname.example.com at EXAMPLE.COM Kerberos: ENC-TS
>> Pre-authentication succeeded -- root/hostname.example.com at
EXAMPLE.COM
>> using arcfour-hmac-md5 Auth: [Kerberos KDC,ENC-TS Pre-authentication]
>> user [(null)]\[root/hostname.example.com at EXAMPLE.COM] at [Thu, 12
Oct
>> 2017 12:49:54.074861 CDT] with [arcfour-hmac-md5] status
>> [NT_STATUS_OK] workstation [(null)] remote host
>> [ipv4:192.168.0.115:40299] became [EXAMPLE]\[HOSTNAME$]
>> [S-1-5-21-3036147387 -4093410917-1991690103-378605]. local host
>> [NULL] authsam_account_ok: Checking SMB password for user
>> root/hostname.example.com at EXAMPLE.COM logon_hours_ok: No hours
>> restrictions for user root/hostname.example.com at EXAMPLE.COM
Kerberos:
>> TGS-REQ root/hostname.example.com at EXAMPLE.COM from
>> ipv4:192.168.0.115:47146 for ldap/dc9.example.com at EXAMPLE.COM
>> [canonicalize] expr:
>> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>> Kerberos: Client no longer in database:
>> root/hostname.example.com at EXAMPLE.COM
>> 
>> 
>> 
>> 
>> 
>> 
>> As you can see, during the AS-REQ, the DC makes 3 queries for
>> specific SPNs and returns positively after finding that last SPN.
>> However, on the TGS-REQ, it only searches for 2 of those SPNs. It is
>> a mystery to me why "expr:
>> (&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))"
>> does not return -- it is not explicitly listed in the
>> "servicePrinicipalName" attribute, but since
>> "root/hostname.example.com" is and "@EXAMPLE.COM"
is the realm, I
>> would think it could figure it out. I'll keep looking into that;
>> however, the lack of the last SPN search seems to me to be a bug.
>> 
>> Any thoughts?
> 
> Yes, you shouldn't have a user called 'root' in AD.
> 'root' is a Unix user and the AD user 'Administrator'
should be mapped
> to 'root'

That makes sense. When I posted earlier, I overlooked that it was searching for
that as a userPrinicpalName, not a servicePrincipalName. I do not have a
"root"
account in AD.


What I don't understand is why that last SPN isn't getting checked in
TGS-REQ
but is in the AS-REQ.

Norbert Hanke

2018-Feb-11 22:27 UTC

head link

[Samba] Opensolaris-ish joins but does not seem to be valid

Hi,

This thread has not been alive for a while...

I'm stuck at the same point: joining the Solaris 11.3 system works but 
using Samba-AD for Solaris-idmap does not work, failing during kerberos 
authentication.

Did you ever find a solution?

regards,

Norbert


On 12.10.2017 21:14, Mike Ray via samba wrote:> ----- On Oct 12, 2017, at 1:52 PM, samba samba at lists.samba.org wrote:
>
>> On Thu, 12 Oct 2017 13:28:40 -0500 (CDT)
>> Mike Ray <mray at xes-inc.com> wrote:
>>
>>> ----- On Oct 11, 2017, at 5:56 PM, samba samba at lists.samba.org
wrote:
>>>
>>>> ----- On Oct 10, 2017, at 12:02 PM, samba samba at
lists.samba.org
>>>> wrote:
>>>>
>>>>> On Tue, 10 Oct 2017 11:28:09 -0500 (CDT)
>>>>> Andrew Martin <amartin at xes-inc.com> wrote:
>>>>>
>>>>>
>>>> Rowland-
>>>>
>>>> I've been poking at this more and think the root of the
problem is
>>>> a Kerberos problem.
>>>>
>>>
>>> I threw the log level up to 10 in /etc/smb.conf on the domain
>>> controller and poked around more.
>>>
>>> Below are some pieces of the log:
>>>
>>>
>>>
>>>
>>>
>>>    Kerberos: AS-REQ root/hostname.example.com at EXAMPLE.COM from
>>> ipv4:192.168.0.115:41751 for krbtgt/EXAMPLE.COM at EXAMPLE.COM
expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>>> expr:
>>>
(&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
>>> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
>>> servicePrincipalName: host/hostname.example.com
servicePrincipalName:
>>> nfs/hostname.example.com servicePrincipalName:
>>> HTTP/hostname.example.com servicePrincipalName:
>>> root/hostname.example.com servicePrincipalName:
>>> cifs/hostname.example.com servicePrincipalName: host/hostname
>>> Kerberos: No preauth found, returning PREAUTH-REQUIRED --
>>> root/hostname.example.com at EXAMPLE.COM Kerberos: AS-REQ
>>> root/hostname.example.com at EXAMPLE.COM from
ipv4:192.168.0.115:40299
>>> for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>>> expr:
>>>
(&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
>>> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
>>> servicePrincipalName: host/hostname.example.com
servicePrincipalName:
>>> nfs/hostname.example.com servicePrincipalName:
>>> HTTP/hostname.example.com servicePrincipalName:
>>> root/hostname.example.com servicePrincipalName:
>>> cifs/hostname.example.com servicePrincipalName: host/hostname
>>> Kerberos: Looking for PKINIT pa-data --
>>> root/hostname.example.com at EXAMPLE.COM Kerberos: Looking for
ENC-TS
>>> pa-data -- root/hostname.example.com at EXAMPLE.COM Kerberos:
ENC-TS
>>> Pre-authentication succeeded -- root/hostname.example.com at
EXAMPLE.COM
>>> using arcfour-hmac-md5 Auth: [Kerberos KDC,ENC-TS
Pre-authentication]
>>> user [(null)]\[root/hostname.example.com at EXAMPLE.COM] at [Thu,
12 Oct
>>> 2017 12:49:54.074861 CDT] with [arcfour-hmac-md5] status
>>> [NT_STATUS_OK] workstation [(null)] remote host
>>> [ipv4:192.168.0.115:40299] became [EXAMPLE]\[HOSTNAME$]
>>> [S-1-5-21-3036147387 -4093410917-1991690103-378605]. local host
>>> [NULL] authsam_account_ok: Checking SMB password for user
>>> root/hostname.example.com at EXAMPLE.COM logon_hours_ok: No hours
>>> restrictions for user root/hostname.example.com at EXAMPLE.COM
Kerberos:
>>> TGS-REQ root/hostname.example.com at EXAMPLE.COM from
>>> ipv4:192.168.0.115:47146 for ldap/dc9.example.com at EXAMPLE.COM
>>> [canonicalize] expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>>> Kerberos: Client no longer in database:
>>> root/hostname.example.com at EXAMPLE.COM
>>>
>>>
>>>
>>>
>>>
>>>
>>> As you can see, during the AS-REQ, the DC makes 3 queries for
>>> specific SPNs and returns positively after finding that last SPN.
>>> However, on the TGS-REQ, it only searches for 2 of those SPNs. It
is
>>> a mystery to me why "expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))"
>>> does not return -- it is not explicitly listed in the
>>> "servicePrinicipalName" attribute, but since
>>> "root/hostname.example.com" is and
"@EXAMPLE.COM" is the realm, I
>>> would think it could figure it out. I'll keep looking into
that;
>>> however, the lack of the last SPN search seems to me to be a bug.
>>>
>>> Any thoughts?
>> Yes, you shouldn't have a user called 'root' in AD.
>> 'root' is a Unix user and the AD user 'Administrator'
should be mapped
>> to 'root'
>
> That makes sense. When I posted earlier, I overlooked that it was searching
for
> that as a userPrinicpalName, not a servicePrincipalName. I do not have a
"root"
> account in AD.
>
>
> What I don't understand is why that last SPN isn't getting checked
in TGS-REQ
> but is in the AS-REQ.
>

Norbert Hanke

2018-Mar-11 15:07 UTC

head link

[Samba] Opensolaris-ish joins but does not seem to be valid

On 12.10.2017 21:14, Mike Ray via samba wrote:> ----- On Oct 12, 2017, at 1:52 PM, samba samba at lists.samba.org wrote:
>
>> On Thu, 12 Oct 2017 13:28:40 -0500 (CDT)
>> Mike Ray <mray at xes-inc.com> wrote:
>>
>>> ----- On Oct 11, 2017, at 5:56 PM, samba samba at lists.samba.org
wrote:
>>>
>>>> ----- On Oct 10, 2017, at 12:02 PM, samba samba at
lists.samba.org
>>>> wrote:
>>>>
>>>>> On Tue, 10 Oct 2017 11:28:09 -0500 (CDT)
>>>>> Andrew Martin <amartin at xes-inc.com> wrote:
>>>>>
>>>>>
>>>> Rowland-
>>>>
>>>> I've been poking at this more and think the root of the
problem is
>>>> a Kerberos problem.
>>>>
>>>
>>> I threw the log level up to 10 in /etc/smb.conf on the domain
>>> controller and poked around more.
>>>
>>> Below are some pieces of the log:
>>>
>>>
>>>
>>>
>>>
>>>    Kerberos: AS-REQ root/hostname.example.com at EXAMPLE.COM from
>>> ipv4:192.168.0.115:41751 for krbtgt/EXAMPLE.COM at EXAMPLE.COM
expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>>> expr:
>>>
(&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
>>> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
>>> servicePrincipalName: host/hostname.example.com
servicePrincipalName:
>>> nfs/hostname.example.com servicePrincipalName:
>>> HTTP/hostname.example.com servicePrincipalName:
>>> root/hostname.example.com servicePrincipalName:
>>> cifs/hostname.example.com servicePrincipalName: host/hostname
>>> Kerberos: No preauth found, returning PREAUTH-REQUIRED --
>>> root/hostname.example.com at EXAMPLE.COM Kerberos: AS-REQ
>>> root/hostname.example.com at EXAMPLE.COM from
ipv4:192.168.0.115:40299
>>> for krbtgt/EXAMPLE.COM at EXAMPLE.COM expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>>> expr:
>>>
(&(servicePrincipalName=root/hostname.example.com)(objectClass=user))
>>> userPrincipalName: host/hostname.example.com at EXAMPLE.COM
>>> servicePrincipalName: host/hostname.example.com
servicePrincipalName:
>>> nfs/hostname.example.com servicePrincipalName:
>>> HTTP/hostname.example.com servicePrincipalName:
>>> root/hostname.example.com servicePrincipalName:
>>> cifs/hostname.example.com servicePrincipalName: host/hostname
>>> Kerberos: Looking for PKINIT pa-data --
>>> root/hostname.example.com at EXAMPLE.COM Kerberos: Looking for
ENC-TS
>>> pa-data -- root/hostname.example.com at EXAMPLE.COM Kerberos:
ENC-TS
>>> Pre-authentication succeeded -- root/hostname.example.com at
EXAMPLE.COM
>>> using arcfour-hmac-md5 Auth: [Kerberos KDC,ENC-TS
Pre-authentication]
>>> user [(null)]\[root/hostname.example.com at EXAMPLE.COM] at [Thu,
12 Oct
>>> 2017 12:49:54.074861 CDT] with [arcfour-hmac-md5] status
>>> [NT_STATUS_OK] workstation [(null)] remote host
>>> [ipv4:192.168.0.115:40299] became [EXAMPLE]\[HOSTNAME$]
>>> [S-1-5-21-3036147387 -4093410917-1991690103-378605]. local host
>>> [NULL] authsam_account_ok: Checking SMB password for user
>>> root/hostname.example.com at EXAMPLE.COM logon_hours_ok: No hours
>>> restrictions for user root/hostname.example.com at EXAMPLE.COM
Kerberos:
>>> TGS-REQ root/hostname.example.com at EXAMPLE.COM from
>>> ipv4:192.168.0.115:47146 for ldap/dc9.example.com at EXAMPLE.COM
>>> [canonicalize] expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))
>>> expr:
(&(objectClass=user)(samAccountName=root/hostname.example.com))
>>> Kerberos: Client no longer in database:
>>> root/hostname.example.com at EXAMPLE.COM
>>>
>>>
>>>
>>>
>>>
>>>
>>> As you can see, during the AS-REQ, the DC makes 3 queries for
>>> specific SPNs and returns positively after finding that last SPN.
>>> However, on the TGS-REQ, it only searches for 2 of those SPNs. It
is
>>> a mystery to me why "expr:
>>>
(&(objectClass=user)(userPrincipalName=root/hostname.example.com at
EXAMPLE.COM))"
>>> does not return -- it is not explicitly listed in the
>>> "servicePrinicipalName" attribute, but since
>>> "root/hostname.example.com" is and
"@EXAMPLE.COM" is the realm, I
>>> would think it could figure it out. I'll keep looking into
that;
>>> however, the lack of the last SPN search seems to me to be a bug.
>>>
>>> Any thoughts?
>> Yes, you shouldn't have a user called 'root' in AD.
>> 'root' is a Unix user and the AD user 'Administrator'
should be mapped
>> to 'root'
>
> That makes sense. When I posted earlier, I overlooked that it was searching
for
> that as a userPrinicpalName, not a servicePrincipalName. I do not have a
"root"
> account in AD.
>
>
> What I don't understand is why that last SPN isn't getting checked
in TGS-REQ
> but is in the AS-REQ.
>With an AD DC based on Samba with the MIT KDC this use case works, 
tested with Samba 4.7.5 on Fedora 27.

The KDC complains a bit:
Mar 11 11:50:54 dc3 krb5kdc[962](info): TGS_REQ (4 etypes {18 17 16 23}) 
192.168.1.5: HANDLE_AUTHDATA: authtime 
1520765454,root/client.ad.domain.ch at AD.DOMAIN.CH for 
ldap/dc3.ad.domain.ch at AD.DOMAIN.CH, Wrong principal in request

but issues the ticket nonetheless.

The same with the Heimdahl compiled-in KDC fails:
[2018/03/11 10:26:19.068905,3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: TGS-REQ root/client.ad.domain.ch at AD.DOMAIN.CH from 
ipv4:192.168.1.5:43766 for ldap/dc2.ad.domain.ch at AD.DOMAIN.CH [canonicalize]
[2018/03/11 10:26:19.089188,3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Client no longer in database: 
root/client.ad.domain.ch at AD.DOMAIN.CH
[2018/03/11 10:26:19.089676,3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
Kerberos: Failed building TGS-REP to ipv4:192.168.1.5:43766

Finally, I got it to work with built-in Heimdahl by renaming the UPN of 
the Computer account from
host/client.ad.domain.ch at AD.DOMAIN.CH
to
root/client.ad.domain.ch at AD.DOMAIN.CH
**
Maybe not really nice, but so far this works.

regards,
Norbert

Apparently Analagous Threads

Search for more apparently analagous threads

samba - Oct 2017 - Opensolaris-ish joins but does not seem to be valid

[Samba] Opensolaris-ish joins but does not seem to be valid

[Samba] Opensolaris-ish joins but does not seem to be valid

[Samba] Opensolaris-ish joins but does not seem to be valid

[Samba] Opensolaris-ish joins but does not seem to be valid

Apparently Analagous Threads