Hi Markus I took a new version of msktutil from their git-repository (http://repo.or.cz/w/msktutil.git). Now, I was able to create a computer-account in the ad with the same msktutil-command as I used before. Corresponding a statement from the msktutil-developer there were some bug fixed (which solved my problems) in the git-version. Thanks a lot for your help. Tom 2010/6/30 Markus Moeller <huaraz@xxxxxxxxxxxxxxxx>: > Hi Tom, > > I have a SLES 11 system I can test tomorrow. It looks like an option is > not available. > > Error: ldap_set_option (option=) failed (Can't contact LDAP server) > > > Markus > > "Tom Tux" <tomtux80@xxxxxxxxx> wrote in message > news:AANLkTimytN03x2ZOV8aFj4_3plnUQ9feA0iWwWddHddx@xxxxxxxxxxxxxxxxx >> >> Hi Markus >> >> Here is the output: >> ------------------ snip ----------------------- >> proxy-test-01:/usr/local/mskutil-0.4/sbin # ./msktutil -c -s >> HTTP/proxy-test-01.xx.yy -h proxy-test-01 -k /etc/krb5.keytab >> --computer-name proxy-test-01 --upn HTTP/proxy-test-01.xx.yy --server >> dc1.xx.yy --verbose >> -- init_password: Wiping the computer password structure >> -- create_fake_krb5_conf: Created a fake krb5.conf file: >> /tmp/.msktkrb5.conf-OINkN1 >> -- reload: Reloading Kerberos Context >> -- finalize_exec: SAM Account Name is: proxy-test-01$ >> -- try_machine_keytab_princ: Trying to authenticate for >> proxy-test-01$ from local keytab... >> -- try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed >> (Key table entry not found) >> -- try_machine_keytab_princ: Authentication with keytab failed >> -- try_machine_keytab_princ: Trying to authenticate for >> host/proxy-test-01.xx.yy from local keytab... >> -- try_machine_keytab_princ: Error: krb5_get_init_creds_keytab failed >> (Client not found in Kerberos database) >> -- try_machine_keytab_princ: Authentication with keytab failed >> -- try_machine_password: Trying to authenticate for proxy-test-01$ >> with password. >> -- try_machine_password: Error: krb5_get_init_creds_keytab failed >> (Preauthentication failed) >> -- try_machine_password: Authentication with password failed >> -- try_user_creds: Checking if default ticket cache has tickets... >> -- finalize_exec: Authenticated using method 4 >> >> -- ldap_connect: Connecting to LDAP server: dc1.xx.yy try_tls=YES >> SASL/GSSAPI authentication started >> SASL username: administrator@xxxxx >> SASL SSF: 0 >> Error: ldap_set_option (option=) failed (Can't contact LDAP server) >> -- ~KRB5Context: Destroying Kerberos Context >> ------------------ snap ----------------------- >> >> The computer-account already exists in the ad (joined with "net ads >> join"). >> The ktutil gives me no principals back: >> >> proxy-test-01:/usr/local/mskutil-0.4/sbin # ktutil >> ktutil: rkt /etc/krb5.keytab >> ktutil: l >> slot KVNO Principal >> ---- ---- >> --------------------------------------------------------------------- >> ktutil: >> >> >> Thanks a lot. >> Kind regards >> Tom >> >> 2010/6/29 Markus Moeller <huaraz@xxxxxxxxxxxxxxxx>: >>> >>> Can you post the whole output of msktutil with --verbose please. If >>> msktutil >>> fails with TLS on port 389 it will try again without TLS. >>> >>> Regards >>> Markus >>> >>> "Tom Tux" <tomtux80@xxxxxxxxx> wrote in message >>> news:AANLkTil1Fhq5Ks3NX8MoSTKIC2qOACz1xpMp6wH6RpkD@xxxxxxxxxxxxxxxxx >>> this works. I'm also able to telnet with tcp 636 (ldaps). >>> >>> I'm just searching for a solution to kerberise squid without the need >>> of winbind/smb. >>> >>> >>> 2010/6/28 Nick Cairncross <Nick.Cairncross@xxxxxxxxxxxxxxx>: >>>> >>>> They seem ok. >>>> >>>> Telnet to your dc on 389? >>>> >>>> >>>> On 28/06/2010 14:40, "Tom Tux" <tomtux80@xxxxxxxxx> wrote: >>>> >>>> which ldap-libraries should be installed? >>>> The following devel-packages are installed (SLES11-System): >>>> - openldap2-devel >>>> - cyrus-sasl-devel >>>> >>>> >>>> >>>> 2010/6/28 Nick Cairncross <Nick.Cairncross@xxxxxxxxxxxxxxx>: >>>>> >>>>> Missing ldap libraries maybe? >>>>> >>>>> >>>>> On 28/06/2010 12:32, "Tom Tux" <tomtux80@xxxxxxxxx> wrote: >>>>> >>>>> Hi >>>>> >>>>> I'm trying to generate a computer-account with msktutil: >>>>> >>>>> I got the following error: >>>>> ... >>>>> ... >>>>> - ldap_connect: Connecting to LDAP server: dc1.domain.com try_tls=YES >>>>> SASL/GSSAPI authentication started >>>>> SASL username: admin@xxxxxxxxxx >>>>> SASL SSF: 0 >>>>> Error: ldap_set_option (option=) failed (Can't contact LDAP server) >>>>> -- ~KRB5Context: Destroying Kerberos Context >>>>> >>>>> >>>>> >>>>> I have a valid ticket (klist), initiated with adminuser@xxxxxxxxxxx >>>>> Have someone any hints? I see, that the msktutil tries with tls >>>>> (encrypted) on port 389 (ldap) on the domain-controller. Can I use >>>>> native (unencrypted) ldap? >>>>> >>>>> Thanks a lot. >>>>> Tom >>>>> >>>>> >>>>> ** 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 >>>>> >>>> >>>> >>>> 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. >>>> >>>> The Conde Nast Publications Ltd (No. 226900), Vogue House, Hanover >>>> Square, >>>> London W1S 1JU >>>> >>> >>> >>> >> > > >