Re: [Samba] samba not using nearest ADS server
Hello James, sorry for the long delay... > I had problems with trusted domains when I migrated to Samba 3.2. We > ended up just deleting the trusts, as they weren't necessary for us but > in your case I don't think that's possible. No, in fact this is no solution for us :-) > Do you get the delay when a German user who is only a member of global > groups for the DE domain logs in? The reason for my long delay was to get such an user for testing: Even the group "Domain Users" is member of other universal groups and (surprise!) one of these groups in located in the UK and another one is located in the US. So I have now an reason why the samba is connecting to the US and to UK - but sill no explanation: There exists an Global Catalog Server in germany, which should replicate the information locally. Why is samba not connecting to that machine? Best regardsTobias > If you set up a test box with "Allow Trusted Domains = No" do you still > see the delay? > > James ZuelowCBJ MIS (907)586-0236 > Network Specialist...Registered Linux User No. 186591 On Tue, Mar 24, 2009 at 12:48:25PM -0800, James Zuelow wrote: > > > > -Original Message- > > From: > > samba-bounces+james_zuelow=ci.juneau.ak...@lists.samba.org > > [mailto:samba-bounces+james_zuelow=ci.juneau.ak...@lists.samba > .org] On Behalf Of Tobias Hennerich > > Sent: Tuesday, 24 March, 2009 11:23 > > To: Mark Casey > > Cc: samba@lists.samba.org > > Subject: Re: [Samba] samba not using nearest ADS server > > > > Hello Mark, > > > > thank you for your reply! > > > > > First, I am assuming from your message that this network > > trace was from > > > one ssh attempt, is that correct? > > > > Yes, that is one login. It doesn't matter if we use ssh or another > > process who needs information about a user. I think we get the same > > result if we just switch to a user from root via "su - user". > > > > > I also gather you are in the germany site? > > > > Yes, the login was a german user to the german server. That user is in > > some universal ADS groups, which are located in germany, too. > > > I had problems with trusted domains when I migrated to Samba 3.2. We > ended up just deleting the trusts, as they weren't necessary for us but > in your case I don't think that's possible. > > Do you get the delay when a German user who is only a member of global > groups for the DE domain logs in? > > If you set up a test box with "Allow Trusted Domains = No" do you still > see the delay? > > James ZuelowCBJ MIS (907)586-0236 > Network Specialist...Registered Linux User No. 186591 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] samba not using nearest ADS server
Hello Mark, thank you for your reply! > First, I am assuming from your message that this network trace was from > one ssh attempt, is that correct? Yes, that is one login. It doesn't matter if we use ssh or another process who needs information about a user. I think we get the same result if we just switch to a user from root via "su - user". > I also gather you are in the germany site? Yes, the login was a german user to the german server. That user is in some universal ADS groups, which are located in germany, too. > So it looks like the auth attempts went to UK and US first before > using your local DC? Please correct me if this is not right. That is correct, the samba connected first to UK and US, then to the german AD. > Also, I'm not quite up to speed with ADS topologies... so is this a > single domain with various sites set up with "AD Sites and Services"? or > is it multiple domains that trust? Each site has it's own ADS domain which trust each other. > or perhaps one domain in a default > site just with routers/mpls handling the jump between subnets? I didn't understand that part of your question completly :-( Each site has an class-b network, (germany: 10.49.0.0/16, uk: 10.44.0.0/16 ...) and the machines have a default route to the next local MPLS-router (more or less). Best regardsTobias On Tue, Mar 24, 2009 at 01:33:23PM -0500, Mark Casey wrote: > Tobias Hennerich wrote: > > Hello, > > > > up to now no response to this mail :-( > > > > Is no one using samba in a wide area network or has no one ever noticed > > such a problem as we are doing? > > > > Tobias > > > > > > On Thu, Mar 19, 2009 at 05:40:46PM +0100, Tobias Hennerich wrote: > > > >> Hello, > >> > >> we integrated an samba v3.2.8 into a bigger ADS environment which is > >> connected via MPLS world wide. Everything works as expected, but the login > >> via SSH is slow: > >> > >> After entering the login name in ssh we can see via tcpdump network > >> traffic to different ADS controllers: > >> > >> First a connection from Germany to UK: > >> > >> 17:16:43.867219 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:44.092774 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:44.092785 IP 10.49.x.y.37722 > 10.44.x.y.389: . > >> 17:16:44.093054 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:44.265776 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:44.265987 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:44.647671 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:44.693567 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:44.693840 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:44.922527 IP 10.44.x.y.389 > 10.49.x.y.37722: . > >> 17:16:44.997865 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:44.998074 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:45.314621 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:45.314831 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:45.577894 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:45.578100 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:45.791494 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:45.791702 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:45.982034 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:45.982240 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:46.189828 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:46.190037 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:46.365426 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:46.365633 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:46.596653 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:46.596900 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:46.802280 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:46.802487 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:47.006571 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:47.006783 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:47.325662 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:47.325868 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:47.577930 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:47.578140 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:47.775371 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:47.775577 IP 10.49.x.y.37722 > 10.44.x.y.389: P > >> 17:16:47.971495 IP 10.44.x.y.389 > 10.49.x.y.37722: P > >> 17:16:47.971704 IP 10.49.x.y.37722 >
Re: [Samba] samba not using nearest ADS server
Hello, up to now no response to this mail :-( Is no one using samba in a wide area network or has no one ever noticed such a problem as we are doing? Tobias On Thu, Mar 19, 2009 at 05:40:46PM +0100, Tobias Hennerich wrote: > Hello, > > we integrated an samba v3.2.8 into a bigger ADS environment which is > connected via MPLS world wide. Everything works as expected, but the login > via SSH is slow: > > After entering the login name in ssh we can see via tcpdump network > traffic to different ADS controllers: > > First a connection from Germany to UK: > > 17:16:43.867219 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:44.092774 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:44.092785 IP 10.49.x.y.37722 > 10.44.x.y.389: . > 17:16:44.093054 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:44.265776 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:44.265987 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:44.647671 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:44.693567 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:44.693840 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:44.922527 IP 10.44.x.y.389 > 10.49.x.y.37722: . > 17:16:44.997865 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:44.998074 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:45.314621 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:45.314831 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:45.577894 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:45.578100 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:45.791494 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:45.791702 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:45.982034 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:45.982240 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:46.189828 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:46.190037 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:46.365426 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:46.365633 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:46.596653 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:46.596900 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:46.802280 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:46.802487 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:47.006571 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:47.006783 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:47.325662 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:47.325868 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:47.577930 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:47.578140 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:47.775371 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:47.775577 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:47.971495 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:47.971704 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:48.186311 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:48.186521 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:48.430837 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:48.431043 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:48.622070 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:48.622274 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:48.816862 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:48.817100 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:49.061838 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:49.062951 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:49.268437 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:49.268634 IP 10.49.x.y.37722 > 10.44.x.y.389: P > 17:16:49.426980 IP 10.44.x.y.389 > 10.49.x.y.37722: P > 17:16:49.466643 IP 10.49.x.y.37722 > 10.44.x.y.389: . > > then a connection from Germany to the United States: > > 17:16:49.547138 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:49.693649 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:49.693662 IP 10.49.x.y.37731 > 10.3.x.y.389: . > 17:16:49.693849 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:49.843729 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:49.843918 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:49.992361 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:49.992553 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:50.129522 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:50.129715 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:50.298217 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:50.298406 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:50.447220 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:50.447408 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:50.589299 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:50.589487 IP 10.49.x.y.37731 > 10.3.x.y.389: P > 17:16:50.748952 IP 10.3.x.y.389 > 10.49.x.y.37731: P > 17:16:50.749139 IP 10.49.x.y.37731 > 10.3.x.y.389: P >
[Samba] samba not using nearest ADS server
Hello, we integrated an samba v3.2.8 into a bigger ADS environment which is connected via MPLS world wide. Everything works as expected, but the login via SSH is slow: After entering the login name in ssh we can see via tcpdump network traffic to different ADS controllers: First a connection from Germany to UK: 17:16:43.867219 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:44.092774 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:44.092785 IP 10.49.x.y.37722 > 10.44.x.y.389: . 17:16:44.093054 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:44.265776 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:44.265987 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:44.647671 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:44.693567 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:44.693840 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:44.922527 IP 10.44.x.y.389 > 10.49.x.y.37722: . 17:16:44.997865 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:44.998074 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:45.314621 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:45.314831 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:45.577894 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:45.578100 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:45.791494 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:45.791702 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:45.982034 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:45.982240 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:46.189828 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:46.190037 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:46.365426 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:46.365633 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:46.596653 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:46.596900 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:46.802280 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:46.802487 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:47.006571 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:47.006783 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:47.325662 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:47.325868 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:47.577930 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:47.578140 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:47.775371 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:47.775577 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:47.971495 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:47.971704 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:48.186311 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:48.186521 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:48.430837 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:48.431043 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:48.622070 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:48.622274 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:48.816862 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:48.817100 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:49.061838 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:49.062951 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:49.268437 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:49.268634 IP 10.49.x.y.37722 > 10.44.x.y.389: P 17:16:49.426980 IP 10.44.x.y.389 > 10.49.x.y.37722: P 17:16:49.466643 IP 10.49.x.y.37722 > 10.44.x.y.389: . then a connection from Germany to the United States: 17:16:49.547138 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:49.693649 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:49.693662 IP 10.49.x.y.37731 > 10.3.x.y.389: . 17:16:49.693849 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:49.843729 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:49.843918 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:49.992361 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:49.992553 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:50.129522 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:50.129715 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:50.298217 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:50.298406 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:50.447220 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:50.447408 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:50.589299 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:50.589487 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:50.748952 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:50.749139 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:50.902596 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:50.902787 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:51.048477 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:51.048669 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:51.16 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:51.200183 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:51.343439 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:51.343626 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:51.509961 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:51.510146 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:51.666507 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:51.96 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:51.809460 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:51.809759 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:51.950416 IP 10.3.x.y.389 > 10.49.x.y.37731: P 17:16:51.950732 IP 10.49.x.y.37731 > 10.3.x.y.389: P 17:16:52.097813 I
[Samba] Strange problems with ADS-groups and winbindd
Hello,
we experience some strange problems with group memberships of ADS users
using samba v3.2.4 on SLES-9. An upgrade to v3.2.7 didn't help.
Changes to the membership of users in ADS universal groups doesn't take
effect at all or take long time (1 day) to be seen on the linux side.
For example the command "net" shows the following GIDs of a user:
# for i in $(net ads user info thenneri -U xxx)
do
getent group $i | awk -F : '{ print $3 }'
done | sort
Enter xxx's password:
10006
10007
10008
10009
10011
10374
The wbinfo shows the following GIDs of the same user:
# wbinfo -r thenneri | sort
10003
10005
10006
10007
10008
10009
10010
10011
10005 is "domain users" - seems to be ok.
10003 is "BUILTIN\users" - I have no idea, how I get into that group.
The group 10010 is wrong! The group 10374 is missing!
After deleting some cache files from winbind, the output of wbinfo looks
more like the net command:
# /etc/init.d/winbind stop
Shutting down Samba WINBIND daemon done
# cd /var/lib/samba
# mv netsamlogon_cache.tdb netsamlogon_cache.tdb.OLD
# mv winbindd_cache.tdb winbindd_cache.tdb.OLD
# /etc/init.d/winbind start
Starting Samba WINBIND daemon done
# wbinfo -r thenneri | sort
10003
10005
10006
10007
10008
10009
10010
10011
10374
The group 10010 is still wrong, but now the missing group 10374 is shown
with both commands.
This output doesn't change for the next few hours until we restart the
nmb-daemon (?!? - restarting winbind or smb doesn't have any effect) :
# /etc/init.d/nmb restart
Shutting down Samba NMB daemon done
Starting Samba NMB daemon done
# wbinfo -r thenneri | sort
10003
10005
10006
10007
10008
10009
10010
10011
Now the group 10374 is missing again!
Our smb.conf looks like this:
[global]
workgroup = XX
realm = xx..com
security = ADS
encrypt passwords = yes
preferred master = no
idmap uid = 1-5
idmap gid = 1-5
winbind use default domain = yes
template shell = /bin/bash
winbind refresh tickets = true
client use spnego = yes
use kerberos keytab = true
winbind cache time = 30
[share]
comment = sharing directory
browseable = yes
available = yes
path = /data/share/
guest ok = no
printable = no
writeable = yes
Has someone any idea how to debug this?
Thank you for your help!
Best regards Tobias
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
