I'm trying to connect my debian machine to a windows server, and can't make it work.
As root, kinit -V [email protected]
returns
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
Password for [email protected]:
Authenticated to Kerberos v5
realm discover MYDOMAIN.COM
gives
mydomain.com
type: kerberos
realm-name: MYDOMAIN.COM
domain-name: mydomain.com
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
I believe I have all the required packages installed, since dpkg-query -l 'sssd-tools' 'sssd' 'adcli' 'samba-common-bin' 'libnss-sss' 'libpam-sss'
returns
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-===================================-======================-======================-===========================================================================
ii adcli 0.8.2-1+b1 amd64 Tool for performing actions on an Active Directory domain
ii libnss-sss:amd64 1.15.0-3 amd64 Nss library for the System Security Services Daemon
ii libpam-sss:amd64 1.15.0-3 amd64 Pam module for the System Security Services Daemon
ii samba-common-bin 2:4.5.8+dfsg-2+deb9u1+ amd64 Samba common files used by both the server and the client
ii sssd 1.15.0-3 amd64 System Security Services Daemon -- metapackage
ii sssd-tools 1.15.0-3 amd64 System Security Services Daemon -- tools
So everything seems fine, but I can't join the network.
realm join --membership-software=adcli MYDOMAIN.COM -U [email protected] --verbose
gives
* Resolving: _ldap._tcp.mydomain.com
* Performing LDAP DSE lookup on: XXX.XX.XXX.XXX
* Performing LDAP DSE lookup on: XXX.XX.XXX.XXX
* Performing LDAP DSE lookup on: XXX.XX.XXX.XXX
* Successfully discovered: mydomain.com
Password for [email protected]:
* Unconditionally checking packages
* Resolving required packages
* LANG=C /usr/sbin/adcli join --verbose --domain mydomain.com --domain-realm MYDOMAIN.COM --domain-controller XXX.XX.XXX.XXX --login-type user --login-user [email protected] --stdin-password
* Using domain name: mydomain.com
* Calculated computer account name from fqdn: myLocalhost
* Using domain realm: mydomain.com
* Sending netlogon pings to domain controller: ldap://XXX.XX.XXX.XXX
* Received NetLogon info from: HI-ROOT03.mydomain.com
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-X6zN48/krb5.d/adcli-krb5-conf-6SRoUP
* Authenticated as user: [email protected]
* Looked up short domain name: MYSHORTDOMAIN
* Using fully qualified name: myLocalhost.mydomain.com
* Using domain name: mydomain.com
* Using computer account name: myLocalhost
* Using domain realm: mydomain.com
* Calculated computer account name from fqdn: myLocalhost
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Found computer account for myLocalhost$ at: CN=myLocalhost,OU=Employee Computers,OU=Place1,OU=UserDevices,OU=Workstations,OU=ENTERPRISE,DC=mydomain,DC=com
! Cannot set computer password: Access denied
adcli: joining domain mydomain.com failed: Cannot set computer password: Access denied
! Insufficient permissions to join the domain
realm: Couldn't join realm: Insufficient permissions to join the domain
The error message seems pretty straightforward to me. The user you're attempting to join as doesn't appear to have permissions to reset the password on the existing "myLocalhost" computer account in that Employee Computers OU.
Should it? Is "myUserName" in the Domain Admins group? If not, has the user been granted other explicit permissions on computer accounts in that OU? Standard user accounts in a well managed Active Directory typically can't just join computers willy nilly.