Robert Cohen
2008-Feb-20 00:47 UTC
[Samba] change in AD authentication behaviour since 3.0.24
We have noticed a change in the way AD authentication behaves starting with 3.0.25. Ive been hoping it was a bug and someone would notice and fix it. But since its still there as of 3.0.28, I guess its a feature :-). Anyway, our users on XP machines used to be able to authenticate against AD with just a username/password eg u1234567. But as of 3.0.25 they need to use a fully qualified username eg XX\u1234567 to authenticate. Otherwise it appears to be attempting to authenticate against the local machine. Is there some setting I can use to get the old behaviour back? Or is the old behaviour simply incorrect, and I'll just have to bite the bullet and re-educate our users. The hassle is that lots of them have canned scripts which they have been carting around forever which use the old behaviour. Just in case theres something in my configuration which is causing the problem, the relevant bits are.>From smb.conf; Security/authentication stuff security = ADS realm = XX.ANU.EDU.AU password server = xx03.anu.edu.au password level = 0 local master = no domain master = no encrypt passwords = yes guest ok = no>From krb5.conf[libdefaults] default_realm = XX.ANU.EDU.AU [realms] XX.ANU.EDU.AU = { kdc = xx01.anu.edu.au kdc = xx02.anu.edu.au kdc = xx03.anu.edu.au admin_server = xx01.anu.edu.au } [domain_realm] .xx.anu.edu.au = XX.ANU.EDU.AU xx.anu.edu.au = XX.ANU.EDU.AU .anu.edu.au = XX.ANU.EDU.AU anu.edu.au = XX.ANU.EDU.AU The "net ads join" commands have been run to add the machine to the AD domain and it was working fine prior to 3.0.25 ======================================Robert Cohen Systems & Desktop Services Division of Information R.G Menzies Building Building 2 The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8389 F: +61 2 6125 7699 http://www.anu.edu.au CRICOS Provider #00120C =======================================
Neal A. Lucier
2008-Feb-20 01:54 UTC
[Samba] change in AD authentication behaviour since 3.0.24
Robert Cohen wrote:> > Anyway, our users on XP machines used to be able to authenticate against AD > with just a username/password eg u1234567. But as of 3.0.25 they need to use > a fully qualified username eg XX\u1234567 to authenticate. > Otherwise it appears to be attempting to authenticate against the local > machine. >winbind use default domain = yes Cheers, Neal
Robert Cohen
2008-Feb-20 03:49 UTC
[Samba] change in AD authentication behaviour since 3.0.24
On 20/2/08 2:40 PM, "Trimble, Ronald D" <Ronald.Trimble@unisys.com> wrote:> We recently submitted a bug for a similar problem, but winbind was not > returning domain information correctly. > https://bugzilla.samba.org/show_bug.cgi?id=5264I'm not sure whether its the same problem as us. BTW I should mention that we're simply not using winbind. The behaviour I'm talking about is when an XP client machine attempts to connect to our server to get a network share. So winbind doesn't enter into the equation.> > > -----Original Message----- > From: Robert Cohen [mailto:robert.cohen@anu.edu.au] > Sent: Tuesday, February 19, 2008 7:13 PM > To: samba@lists.samba.org > Subject: [Samba] change in AD authentication behaviour since 3.0.24 > > We have noticed a change in the way AD authentication behaves starting with > 3.0.25. Ive been hoping it was a bug and someone would notice and fix it. > But since its still there as of 3.0.28, I guess its a feature :-). > > Anyway, our users on XP machines used to be able to authenticate against AD > with just a username/password eg u1234567. But as of 3.0.25 they need to use > a fully qualified username eg XX\u1234567 to authenticate. > Otherwise it appears to be attempting to authenticate against the local > machine. > > > Is there some setting I can use to get the old behaviour back? > Or is the old behaviour simply incorrect, and I'll just have to bite the > bullet and re-educate our users. The hassle is that lots of them have canned > scripts which they have been carting around forever which use the old > behaviour. > > Just in case theres something in my configuration which is causing the > problem, the relevant bits are. > >> From smb.conf > > ; Security/authentication stuff > security = ADS > realm = XX.ANU.EDU.AU > password server = xx03.anu.edu.au > password level = 0 > local master = no > domain master = no > encrypt passwords = yes > guest ok = no > >> From krb5.conf > [libdefaults] > default_realm = XX.ANU.EDU.AU > > [realms] > XX.ANU.EDU.AU = { > kdc = xx01.anu.edu.au > kdc = xx02.anu.edu.au > kdc = xx03.anu.edu.au > admin_server = xx01.anu.edu.au > } > > [domain_realm] > .xx.anu.edu.au = XX.ANU.EDU.AU > xx.anu.edu.au = XX.ANU.EDU.AU > .anu.edu.au = XX.ANU.EDU.AU > anu.edu.au = XX.ANU.EDU.AU > > > The "net ads join" commands have been run to add the machine to the AD > domain and it was working fine prior to 3.0.25 > > > > > > ======================================> Robert Cohen > Systems & Desktop Services > Division of Information > R.G Menzies Building > Building 2 > The Australian National University > Canberra ACT 0200 Australia > > T: +61 2 6125 8389 > F: +61 2 6125 7699 > http://www.anu.edu.au > > CRICOS Provider #00120C > ======================================> > >======================================Robert Cohen Systems & Desktop Services Division of Information R.G Menzies Building Building 2 The Australian National University Canberra ACT 0200 Australia T: +61 2 6125 8389 F: +61 2 6125 7699 http://www.anu.edu.au CRICOS Provider #00120C =======================================
Robert Cohen
2008-Feb-21 00:31 UTC
[Samba] change in AD authentication behaviour since 3.0.24
Charles Marcus CMarcus at Media-Brokers.com wrote>>On 2/19/2008, Robert Cohen (robert.cohen at anu.edu.au) wrote: I'm not sure >>whether its the same problem as us.>> BTW I should mention that we're simply not using winbind. The behaviour I'm >> talking about is when an XP client machine attempts to connect to our server >> to get a network share. >> >> So winbind doesn't enter into the equation. >> >From the 3.0.25 release notes (3rd paragraph is most relevant to you):>"Member servers, domain accounts, and smb.conf >============================================ >Since Samba 3.0.8, it has been recommended that all domain accounts listed >In smb.conf on a member server be fully qualified with the domain name. >This is now a requirement. All unqualified names are assumed to be local to >the Unix host, either as part of the server's local passdb or in the local >system list of accounts (e.g. /etc/passwd or /etc/group). > >The reason for this change is that smbd has transitioned from access checks >based on string comparisons to token based authorization. All names are >resolved to a SID and then verified against the logged on user's NT user >token. Local names will resolve to a local SID, while qualified domain >names will resolve to the appropriate domain SID. >If the member server is not running winbindd at all, domain accounts will be >implicitly mapped to local accounts and their tokens will be modified >appropriately to reflect the local SID and group membership. >This turned out to be the problem. We hadnt been starting winbindd since I thought it was only relevant if you were using winbind in /etc/nsswitch.conf. But as soon as we started winbind, along with other config settings mentioned earlier, everything just started working. ======================================Robert Cohen