2011-12-31 19:17 keltezéssel, steve írta: > On 31/12/11 17:39, steve wrote: >> On 31/12/11 16:14, steve wrote: >>> On 31/12/11 12:48, Gémes Géza wrote: >>>> 2011-12-30 13:21 keltezéssel, steve írta: >>>>> On 30/12/11 13:09, steve wrote: >>>>>> On 30/12/11 09:38, steve wrote: >>>>>>> On 29/12/11 19:14, Gémes Géza wrote: >>>>>>>> 2011-12-29 12:56 keltezéssel, steve írta: >>>>>>>>> On 29/12/11 11:58, Gémes Géza wrote: >>>>>>>>>> 2011-12-29 10:11 keltezéssel, steve írta: >>>>>>>>>>> On 29/12/11 10:00, steve wrote: >>>>>>>>>>>> On 28/12/11 21:59, Bernd Markgraf wrote: >>>>>>>>>>>>>> You should create a user in AD for nss-ldap and extract a >>>>>>>>>>>>>> keytab >>>>>>>>>>>>>> for it >>>>>>>>>>>>>> (samba-tool domain exportkeytab --principal=....) and >>>>>>>>>>>>>> configure >>>>>>>>>>>>>> nss-ldap >>>>>>>>>>>>>> to use that keytab for authenticating. Most probably you >>>>>>>>>>>>>> aren't >>>>>>>>>>>>>> allowed >>>>>>>>>>>>>> to bind anonymously to your AD server (you can try with >>>>>>>>>>>>>> ldapsearch -x) >>>>>>>>>>>>> LDAP works with an anonymous bind. You need the Kerberos >>>>>>>>>>>>> keytab for >>>>>>>>>>>>> authentication though. >>>>>>>>>>>>> >>>>>>>>>>>> steve@hh3:~> ldapsearch -x >>>>>>>>>>>> # extended LDIF >>>>>>>>>>>> # >>>>>>>>>>>> # LDAPv3 >>>>>>>>>>>> # base<DC=hh3,DC=site> (default) with scope subtree >>>>>>>>>>>> # filter: (objectclass=*) >>>>>>>>>>>> # requesting: ALL >>>>>>>>>>>> # >>>>>>>>>>>> >>>>>>>>>>>> # search result >>>>>>>>>>>> search: 2 >>>>>>>>>>>> result: 1 Operations error >>>>>>>>>>>> text: 00002020: Operation unavailable without authentication >>>>>>>>>>>> >>>>>>>>>>>> # numResponses: 1 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I found this usage: >>>>>>>>>>>> >>>>>>>>>>>> samba-tool export keytab PATH_TO_KEYTAB >>>>>>>>>>>> >>>>>>>>>>>> How can I find my PATH_TO_KEYTAB >>>>>>>>>>>> ? >>>>>>>>>>>> Thanks >>>>>>>>>>> Can't get the syntax right: >>>>>>>>>>> >>>>>>>>>>> samba-tool domain exportkeytab /var/lib/named/master >>>>>>>>>>> --principal >>>>>>>>>>> >>>>>>>>>>> Usage: samba-tool domain exportkeytab<keytab> [options] >>>>>>>>>>> >>>>>>>>>>> samba-tool domain exportkeytab: error: --principal option >>>>>>>>>>> requires an >>>>>>>>>>> argument >>>>>>>>>>> >>>>>>>>>> samba-tool domain exportkeytab >>>>>>>>>> /path/to/the/keytab/file/you/want/to/create/or/update >>>>>>>>>> --principal=the_name(samAccountName_or_spn_created_with_samba-tool_spn)_of_the_principal_you_want_to_extract >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards >>>>>>>>>> >>>>>>>>>> Geza >>>>>>>>> Tried: >>>>>>>>> samba-tool domain exportkeytab /etc/krb5.keytab >>>>>>>>> --principal=steve4 >>>>>>>>> >>>>>>>>> restarted samba but: >>>>>>>>> >>>>>>>>> su steve4 >>>>>>>>> su: user steve4 does not exist >>>>>>>>> >>>>>>>>> Am I getting close or should I give up now?! >>>>>>>>> >>>>>>>>> Steve >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> You still need to configure nss-ldap to do a kerberized bind. >>>>>>>> I've found example configurations for nslcd (the daemon part of >>>>>>>> nss-ldapd a fork of nss-ldap) at: >>>>>>>> http://lists.arthurdejong.org/nss-pam-ldapd-users/2010/msg00125.html >>>>>>>> >>>>>>>> http://ubuntuforums.org/archive/index.php/t-1335022.html >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Geza >>>>>>> phew. That's a biggie. >>>>>>> >>>>>>> I have nslcd installed. I've looked at the links and it seems as >>>>>>> though I need this in /etc/nslcd.conf >>>>>>> >>>>>>> uri ldap://127.0.0.1/ >>>>>>> base dc=hh3,dc=site >>>>>>> sasl_mech GSSAPI >>>>>>> sasl_realm HH3.SITE >>>>>>> krb5_ccname /dont/know >>>>>>> >>>>>>> It's the krb5_ccname I can't get. >>>>>>> >>>>>>> I have: >>>>>>> klist >>>>>>> Ticket cache: FILE:/tmp/krb5cc_0 >>>>>>> Default principal: ste...@hh3.site >>>>>>> >>>>>>> Valid starting Expires Service principal >>>>>>> 12/30/11 09:27:15 12/30/11 19:27:15 krbtgt/hh3.s...@hh3.site >>>>>>> renew until 12/31/11 09:27:12 >>>>>>> >>>>>>> The link you gave suggests: >>>>>>> >>>>>>> krb5_ccname /var/run/nslcd/nslcd.tkt >>>>>>> >>>>>>> But doesn't say where that came from. >>>>>>> >>>>>>> Any ideas? >>>>>>> >>>>>>> Saludos >>>>>>> Steve >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Well, using nslcd, I have finally got through to the Samba 4 LDAP ( >>>>>> >>>>>> getent passwd works and steve4 can finally login >>>>>> >>>>>> The next bit is this: >>>>>> >>>>>> getent passwd does not show the home directory: >>>>>> steve4:x:3000019:100:steve4::/bin/bash >>>>>> >>>>>> even though I can see it in the ldap ldif >>>>>> >>>>>> steve4 gets logged into / but changing to /home/CACTUS/steve4 allows >>>>>> him to create and edit files correctly and with the correct >>>>>> permissions. >>>>>> >>>>>> Any ideas? >>>>>> Thanks >>>>>> Steve. >>>>>> >>>>> Found it: >>>>> >>>>> map passwd homeDirectory unixHomeDirectory >>>>> >>>>> so /etc/nslcd.conf looks like this: >>>>> >>>>> uri ldap://127.0.0.1/ >>>>> base dc=hh3,dc=site >>>>> map passwd homeDirectory unixHomeDirectory >>>>> sasl_mech GSSAPI >>>>> sasl_realm HH3.SITE >>>>> krb5_ccname /tmp/krb5cc_0 >>>>> >>>>> Cheers, >>>>> Steve >>>>> >>>> Hi, >>>> >>>> I'm glad it works now >>>> Sorry for the late answer yesterday my ISPs (I have two just to be >>>> sure) >>>> both decided at the same time to redo the routing of their networks >>>> ==> >>>> got off-line for most of the day :-(. >>>> >>>> Happy New Year! >>>> >>>> Regards >>>> >>>> Geza >>> Hi Geza >>> Nearly works. Getent passwd works and su user works from root but >>> the user can't login unless he's in a root shell. I think this has >>> something to do with pam. I had it working fine this morning until I >>> disabled the ldap client in opensuse having thought that it would be >>> affecting the process. Now no logins apart from in a root shell. I >>> played around with some pam libraries a few weeks ago: >>> >>> Dec 31 16:09:51 hh3 nslcd[7090]: version 0.7.13 starting >>> Dec 31 16:09:51 hh3 nslcd[7090]: accepting connections >>> Dec 31 16:09:51 hh3 nslcd[7082]: Starting local LDAP Name Service >>> Daemon..done >>> Dec 31 16:10:04 hh3 su: (to steve2) steve on /dev/pts/0 >>> Dec 31 16:10:14 hh3 login[6755]: FAILED LOGIN SESSION FROM /dev/tty1 >>> FOR steve2, Authentication failure >>> Dec 31 16:10:17 hh3 systemd[1]: getty@tty1.service holdoff time >>> over, scheduling restart. >>> Dec 31 16:10:27 hh3 polkitd(authority=local): nss_ldap: could not >>> search LDAP server - Server is unavailable >>> Dec 31 16:10:27 hh3 polkitd(authority=local): nss_ldap: reconnecting >>> to LDAP server (sleeping 4 seconds)... >>> Dec 31 16:10:31 hh3 polkitd(authority=local): nss_ldap: reconnecting >>> to LDAP server (sleeping 8 seconds)... >>> Dec 31 16:10:39 hh3 polkitd(authority=local): nss_ldap: reconnecting >>> to LDAP server (sleeping 16 seconds)... >>> Dec 31 16:10:55 hh3 polkitd(authority=local): nss_ldap: reconnecting >>> to LDAP server (sleeping 32 seconds)... >>> Dec 31 16:11:20 hh3 su: FAILED SU (to steve5) steve on /dev/pts/0 >>> Dec 31 16:11:27 hh3 polkitd(authority=local): nss_ldap: reconnecting >>> to LDAP server (sleeping 64 seconds)... >>> >>> Am so close on this I feel. >>> Any ideas where to look? >>> >>> Que nos traigan suerte las uvas!! >>> Feliz 2012 >>> Steve >> It does seem to be to do with pam: >> >> Dec 31 17:34:24 hh3 su: pam_unix(su:auth): authentication failure; >> logname=steve uid=1000 euid=0 tty=pts/1 ruser=steve rhost= user=lynn2 >> >> steve is the logged in local user, lynn2 the samba4/ldap user >> >> Ahggh!! >> Where do I change that? >> >> Steve >> > Hi Geza, hi everyone > > Sorry 2 b such a pain. It was a pam problem. I logged off and could > not get back in. Fortunately I could overwrite pam.d with a copy from > a working machine that also had ldap. > > So, its not been easy but that's win 7 domain logons, linux logons and > nfs4 file server all from the same Samba 4 box. Is this good enough to > join Samba Technical and argue my point about Samba4/rfc2307 for Linux > clients? I'll blog my findings anyway. I just don't want to trouble > anyone. > > Steve > > > Steve > Congrats!
You weren't a pain. We are here to help, and to get helped as well, that is called community support (in my experience it works lot more reliable than some commercial one). IMHO a head-ups about winbind4 in the samba-technical mailing list wouldn't hurt. Happy New Year! Geza -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba