After upgrading from Windows 2000 to Windows 7 we have the problem that all users with usernames > 20 chars cannot login any more. Immediately after logging in with the correct password Windows 7 prints "Data area passed to a system call is too small" and logs off the user again. Even if I create an alias for a user with < 20 chars the same issue arises. This workaround worked for W95 in the past. I'm not sure how samba related this issue is (its critical to me), but when I googled I found out that in ActiveDirectory the usernames length can be up to 64 chars (at least) and found no issues like this with a "real" Windows PDC.
To add some more information: 1. Windows7 checks correctly the credentials for usernames with length > 20 chars. 2. The user domain-logon seems to be "successful": Windows 7 copies the "netlogon\Default user" to the user "homes"-share as NTProfile.V2 - but then somehow the wired error-message appears and the user is logged off again. 3. If I log on the Win7 client locally (with e.g. Administrator), open the samba-server in explorer using \\fileserver, then Win7 asks me for credentials, I enter a >20-chars-username then it works w/o problems. 4. If I create an alias (using smbusers) with < 20 chars pointing to the >20-chars-username it doesn't work, too. - Windows7 seems to use the real username after logon. My (crappy) workaround (maybe this helps solving it if its a samba issue): I use ldap with DN like this: uid=sometimesverylongusername,ou=people,dc=a,dc=de. Now I renamed the DN to uid=shorter,ou=people,dc=a,dc=de and put another uid-attribute with the real "sometimesverylongusername" username into the entry. This way Windows7/Samba finds the long username (using the uid-lookup) and reports the shorter name to Windows7. (Not nice, because ppl. now have two usernames, but its working).
I just upgraded from 3.4.7 to 3.5.2 - issue is still there.
Please upload a network trace of the failure together with a debug level 10 log of smbd. http://wiki.samba.org/index.php/Capture_Packets Thanks, Volker
Created attachment 5642 [details] tcpdump
Created attachment 5643 [details] smbd.log
You seem to have a "log file = " parameter set. The log.smbd file is not complete, please send the logfile for the specific user/machine. Volker
Created attachment 5653 [details] tcpdump
Created attachment 5654 [details] smbd.log hopefully complete log now
Reproduced the issue. I don't think this is anything we can fix in Samba 3 (without the AD DC code). This really smells like a bug in the Windows 7 code that provides the "legacy" authentication provider. I'll try to contact Microsoft, maybe they can take a quick look at their code. Volker
> My (crappy) workaround (maybe this helps solving it if its a samba issue): > I use ldap with DN like this: > uid=sometimesverylongusername,ou=people,dc=a,dc=de. > Now I renamed the DN to uid=shorter,ou=people,dc=a,dc=de ... Thxs for your "not so crappy" workaround. It is not require to change the dn, add some short length uid that's all! U can open a session under Seven with the long length login (or the short without lose your profile) With your example: uid=sometimesverylongusername,ou=people,dc=a,dc=de. Just add this uid: uid=niceshortname Your ldap entry (dn: uid=sometimesverylongusername,ou=people,dc=a,dc=de) have 2 uid: uid=sometimesveryongusername uid=niceshortname Your seven use the username: sometimesveryongusername to open the session and for your profile. Pascal B.
(In reply to comment #10) > Your ldap entry (dn: uid=sometimesverylongusername,ou=people,dc=a,dc=de) have 2 > uid: > uid=sometimesveryongusername > uid=niceshortname > > Your seven use the username: sometimesveryongusername to open the session and > for your profile. That did not work with the samba version I reported the bug. Somehow it switched to the long name internally and so the problem was still there.
> That did not work with the samba version I reported the bug. Somehow it > switched to the long name internally and so the problem was still there. K Right, I tested with Samba 3.4.5
> That did not work with the samba version I reported the bug. Somehow it > switched to the long name internally and so the problem was still there. I confirm the bug with Samba 3.5.6, le dn must be short :-(
> that provides the "legacy" authentication provider. I'll try to contact > Microsoft, maybe they can take a quick look at their code. Any news from Ms ?
(In reply to comment #13) > > That did not work with the samba version I reported the bug. Somehow it > > switched to the long name internally and so the problem was still there. > > I confirm the bug with Samba 3.5.6, le dn must be short :-( erratum: "my" workaround works with samba 3.5.6. But the position of the short uid is important: u must place it before the long one. The result of ldapsearch must be something like this: #ldapsearch -x uid=sometimesverylongusername dn: uid=sometimesverylongusername,ou=Population,.... (cut) ... (cut) uid=niceshortname uid=sometimesveryongusername With this way the Seven authentification with sometimesverylongusernam work ... but niceshortname is display in the domain users list. # pdbedit -Lv sometimesveryongusername return init_sam_from_ldap: Entry found for user: niceshortname Unix username: niceshortname NT username: niceshortname
Any other solution ? Or a possible Microsoft HotFix ? I have more then 600 users in my Samba domain with more than 20 characters. Using Samba 3.5 + ldapsam
Someone needs to contact Microsoft with a fairly high-level support request. I tried, but failed.
I also manage a network with 700 users. Their usernames were "givenname.surname" for years. I follewed the idea of Pascal BASTIEN to add a new uid line before the existing lines. My shortnames looks like: g.surname. This script helps me to add the new lines: lines=$(cat data.ldif | grep -n "uid:" | tr " " "_" | paste -s); nn=0; \ for line in $lines; do nr=$(echo $line | cut -d":" -f1); nr2=$(( $nr-1+$nn )); nn=$(( $nn+1 )); \ name=$(echo $line | cut -d"_" -f2-); NAME=$(echo "`echo $name |cut -c1`.`echo $name | cut -d"." -f2-`"); \ echo "$nr $nr2 $name $nn"; sed -i "${nr2}s/\$/\nuid: ${NAME}/g" newdata.ldif; done To find duplicate entries, I use this: cd /home name=$(ls -d */ | cut -d"/" -f1); for i in $name; do givenname=$(echo $i | cut -c1 ); \ surname=$(echo $i | cut -d"." -f2-); echo "$givenname.$surname" >> /root/people.txt; done cat /root/people.txt | sort | uniq -D > /root/duplicate.txt It's not perfect, but it works!
obviously a new and intended limitation in win7, see: http://social.technet.microsoft.com/Forums/en/w7itprogeneral/thread/738de1c9-494a-43ac-bef9-b03804ce43ca <quote> No. It is fixed at 20 characters for the local username. This is by design regarding the backward compatibility reason. You may name in AD to get pass the 20 charators. Reference: 2.4 String Field Length Limits </quote>
Hi, Fortunately this limitation/ bug / functionnality(?) seems to be passed away on Windows 8 Beta 32 bits (Consumer Preview version): Windows 8 Consumer Preview: http://windows.microsoft.com/en-US/windows-8/iso I tested with Samba 3.5.6 DC and a lonnnnnng LDAP account: uid: constantine.berdadotte-bayeux It's work fine. then I think we must discover the secret registry parameter on windows Seven...
this is or was an intended Windows limitation, not a samba bug. closing this bug accordingly.