I've got following configuration: Two domains: ADSDOMAIN run by ADS computer with Windows 2003 with member XP VORAGO domain run by samba PDC with member PC1 I've set up a trust between VORAGO and ADSDOMAIN, it worked without a problem. I've configured pam on PDC and on PC1. PC1 could list ADS users with wbinfo -u (or getent) while PDC could not. PC1 and PDC couldn't perform authentication of XP computer with wbinfo -a. And XP couldn't log into PC1 nor PDC. wbinfo with valid password ended in NT_STATUS_NO_LOGON_SERVERS, while when the password was incorrect i received NT_WRONG_PASSWORD reply. So it was possible to get the information if the password was correct. This problem was solved by adding krb5.conf to PDC, but I don't understand why it was needed there --- i guess authorization should be possible with only NT protocols (could be the windows 2003 misconfigured? I've only set there a domain and trust). Also I hadn't seen a single word about kerberos configuration in the "inter-domain trusts" of Samba HOWTO. Also I don't know how would this configuration behave with PDC being a NT server. ---- Another problem is with "allow trusted domains" option. Manual says: allow trusted domains (G) This option only takes effect when the security option is set to server,domain or ads. If it is set to no, then attempts to connect to a resource from a domain or workgroup other than the one which smbd is running in will fail, even if that domain is trusted by the remote server doing the authentication. But it's untrue. Setting "allow trusted domains = no" on PDC (with security=user) caused all computers in PDC domain to be unable to authorize XP computer. They could list ADSDOMAIN users nevertheless. Setting that option to "yes" on PDC, and "no" on PC1 enabled PC1 to authenticate users with wbinfo -a, but did not allow XP login (quite correct). I'm not sure if it's samba error or manual mistake, and which behavior is correct, but it had caused me many problems. Cheers, bla PS. PDC was x86_64, and PC1 x86.
just replying on the first reported issue here: i've also seen that a trust against an AD domain fails by default because there is no krb5 domain configured for that trusted domain. I least I saw that recently in a one-way trust setup where net rpc trustdom establish failed in the first place because of the missing krb5 configuration for that AD domain. I think we should create a krb5.conf for such a setup also so that the AD domain can be contacted kerberized. BTW: as a workaround you can set winbind rpc only = yes to skip the failing kerberos path. Günther, can you have a look and may I assign this one to you?