I haven't seen this error before. Is your AD 2008 ? Has the schema been
changed ?
These are the only attributes used by msktutil and are the default ones
UserPrincipalName;
DnsHostName;
Description;
ManagedBy;
OperatingSystem;
ObjectClass;
CN;
UserAccountControl;
SamAccountName;
supportedEncryptionTypes;
Regards
Markus
"Nick Cairncross" <Nick.Cairncross_at_condenast.co.uk> wrote in message
news:C7E4FB76.1ED6D%Nick.Cairncross_at_condenast.co.uk...
Markus,
I've had a go with mskstutil and it appeared to work partially once - the
comptuer account was created and the spn/upn were set, but no Keytab was
generated.. I then tried again having deleted the squid-http computer
account but receive the following errors - see below, at the end. Would you
be able to advise as to where I should look to try to resolve this? I have
also rolled back my VM, removed from domain etc and retried with no success.
Many thanks,
Nick
[root_at_bnd-squid1 msktutil-0.3.16]# ./msktutil -c -b "CN=COMPUTERS" -s
HTTP/bnd-squid1.[MYFQDN] -h bnd-squid1.[MYFQDN] -k
/etc/squid/HTTP.keytab --computer-name squid-http --upn
HTTP/bnd-squid1.[MYFQDN] --server bnd-dc4 --verbose --enctypes 28
-- init_password: Wiping the computer password structure
-- finalize_exec: Determining user principal name
-- finalize_exec: User Principal Name is: HTTP/bnd-squid1.[MYFQDN]@[MYFQDN]
-- create_fake_krb5_conf: Created a fake krb5.conf file:
/tmp/.mskt-9522krb5.conf
-- get_krb5_context: Creating Kerberos Context
-- try_machine_keytab: Using the local credential cache:
/tmp/.mskt-9522krb5_ccache
-- try_machine_keytab: krb5_get_init_creds_keytab failed (Client not found
in Kerberos database)
-- try_machine_keytab: Unable to authenticate using the local keytab
-- ldap_connect: ldap_connect calling try_ldap_connect
-- try_ldap_connect: Connecting to LDAP server: bnd-dc4 try_tls=YES
-- try_ldap_connect: Connecting to LDAP server: bnd-dc4 try_tls=NO
SASL/GSSAPI authentication started
SASL username: ncairncross@[MYFQDN]
SASL SSF: 56
SASL installing layers
-- try_ldap_connect: LDAP_OPT_X_SASL_SSF=56
-- ldap_get_base_dn: Determining default LDAP base: dc=XX,dc=XXXX,dc=XXX
-- get_short_hostname: Determined short hostname: bnd-squid1
-- finalize_exec: SAM Account Name is: squid-http$
Updating all entries for bnd-squid1 in the keytab /etc/squid/HTTP.keytab
-- try_set_password: Attempting to reset computer's password
-- ldap_check_account: Checking that a computer account for squid-http$
exists
-- ldap_check_account: Computer account not found, create the account
No computer account for squid-http found, creating a new one.
Error: ldap_add_ext_s failed (No such attribute)
Error: ldap_check_account failed (Device or resource busy)
Error: set_password failed
-- krb5_cleanup: Destroying Kerberos Context
-- ldap_cleanup: Disconnecting from LDAP server
-- init_password: Wiping the computer password structure
On 08/04/2010 20:08, "Markus Moeller" <huaraz_at_moeller.plus.com> wrote:
Hi Nick,
Did you use samba to create the keytab. I have seen that if you use samba
for more then squid (e.g. cifs, winbind, etc) it will update regularly the
AD entry and key for the host/fqdn principal which is the same as for
HTTP/fqdn. I usually use msktutil and create a second AD entry called
<short-hostname>-HTTP to be independent of samba which usually uses
<short-hostname>.
Regards
Markus
** Please consider the environment before printing this e-mail **
The information contained in this e-mail is of a confidential nature and is
intended only for the addressee. If you are not the intended addressee, any
disclosure, copying or distribution by you is prohibited and may be
unlawful. Disclosure to any party other than the addressee, whether
inadvertent or otherwise, is not intended to waive privilege or
confidentiality. Internet communications are not secure and therefore Conde
Nast does not accept legal responsibility for the contents of this message.
Any views or opinions expressed are those of the author.
Company Registration details:
The Conde Nast Publications Ltd
Vogue House
Hanover Square
London W1S 1JU
Registered in London No. 226900
Received on Fri Apr 09 2010 - 16:13:12 MDT
This archive was generated by hypermail 2.2.0 : Fri Apr 09 2010 - 12:00:03 MDT