Hi joe, I feel privileged to get such a detailed answer. I figured this was the answer but thought I would ask, I searched for a day or so and didn't find anything. The reason I am looking to do this is we use a barracuda for spam filtering and looking to use AD/LDAP to help performance and implement some additional features LDAP provides. When the barracuda unit has LDAP turned on, the ID it brings back from AD is the samAccountName. Without having extra tricky logic to create the unique samAccountName on the fly it comes down to choosing some 'concept' to generate this name. I would prefer to just put something that is longer than 20 characters (email address or whatever). I never figured coming up with a unique naming standard algorithm would be such a trick. Thanks again!
Thank you, Steve Schofield Microsoft MVP - ASP/ASP.NET ASPInsider Member - MCP http://www.orcsweb.com/ Powerful Web Hosting Solutions #1 in Service and Support -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, February 20, 2005 11:37 AM To: [email protected] Subject: SPAM-LOW: RE: [ActiveDir] samAccountName attribute length This is actually a great question. I was hoping to see the one person who I would really trust this answer to and see that he is currently away. So I will show how much I don't know... He will laugh because we had a similar conversation recently. Not on these specifics, but the general concept of the SAM. The answer is no. At least not at this time and it is me guessing, but I expect probably never. At this exact moment in time, the length is currently hardcoded regardless of the value specified in the schema for sAMAccountName which is 256. If I recall, in early early 2K prior to 2K name it was something like 64 in the schema even. F:\DEV\>adfind -schema -f ldapdisplayname=samaccountname rangeupper AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005 Using server: 2k3dc01.joe.com Directory: Windows Server 2003 Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com dn:CN=SAM-Account-Name,CN=Schema,CN=Configuration,DC=joe,DC=com >rangeUpper: 256 1 Objects returned Here is where I will probably get thunked if I say something wrong... The idea here, from my understanding, is that LDAP actually sits on the SAM functionality. Basically you have something like --------------- | | | LDAP | | | --------------- --------------- | | | SAM | | | --------------- Instead of duplicating all of the SAM rules in the LDAP pieces of code, it would make sense to push to some extent the restriction checking if not all of the logic for SAM Based attributes (legacy attributes) down through the actual SAM code. That way you minimize the chance of bugs where doing something with one interface works and doing it with another doesn't. So anyway, in Windows 2000 and even Windows Server 2003 SAM info is stored in two different stores. The registry just like it was in NT4 and in the DIT. I am not saying that all of your AD Users are stored in the Registry, I am saying that on any given Windows 2000 or even 2003 machine, the info could either be in the DIT or in the registry. Consider the local account structure on workstations, member servers, standalone servers and even domain controllers in terms of the recovery ID or the single session ID if you prefer - what is used when you don't let DS start. This registry piece I expect still has the structure limits it had under NT4 and I would guess that changing that would be a substantial piece of work. I expect what we will instead see and IMO think we are already seeing is to be led away from using sAMAccountName. You will see greater and greater reliance on UPN instead. In fact I may have heard this offhand at some point now that I think about it but I could be thinking to a conversation amongst MVPs guessing at the future, possibly I am remembering talking about my own guesses. :o) Anyway, if you look at NT4, sAMAccountName was actually LogonName or UserID, ditto for local accounts, it is the one, the only userid. In NT5.0 we got UPN, however sAMAccountName was still required to be configured on account add. This I think is obvious or else migrations would have been a bitch. In NT5.2, we still have both, but you no longer have to specify the sAMAccountName during account create. If you don't, MS assigns a random value to the sAMAccountName. You will see something like $158000-BHEOPLC0V073. I don't expect MS expects anyone to get that as their userid to use. It is simply a placeholder so all of the SAM logic holds up. Easier to put in a bogus but unique 20 chars or less placeholder value than change all of the underlying SAM code. This is one reason I tend to tell people to try and keep sAMAccountNames AND userids unique in the forest. Not just unique in a domain. Say I have a forest called company.com. It has several domains. I let people create IDs as they want instead of going through some centralized rules system and I end up with (OMG!) a joe samaccountname/userid in three different domains but you figure hey, that is fine it is *REALLY* domain1\joe, domain2\joe, and domain3\joe; no big cheese (I would argue that btw from a confusion standpoint and a nice bug err feature in the E2K3 mailbox reconnect WMI functionality). Now we step forward in time a few virtual years and all of a sudden MS is like, your primary ID is now no longer SAM ID and you get some sort of penalty for using it. Not anything harsh, but maybe some new feature doesn't work with the SAM ID or it is a little slower, something like that. Ok, great, so the "new" userid format of choice is the UPN... [EMAIL PROTECTED] This can obviously be set to just about anything, but for users who have been using the SAM name for years you would generally expect this to be something hopefully close to the SAM name and maybe the email address which will probably be something like [EMAIL PROTECTED] or [EMAIL PROTECTED] Out of the two, I prefer [EMAIL PROTECTED] Less of a jump for many users. Generally less to type, I certainly wouldn't want to go from typing domain\samname to [EMAIL PROTECTED] Whoops, if you have duplicate SAM Names, this isn't going to work for you without a lot of work cleaning up... If you go the other way, lots of room for dupes with [EMAIL PROTECTED] as well, I actually had someone at MSU back in the 80's that shared my entire name with me. He lived on the other side of campus and we often got each other's mail. That was only 40k people in the space of 3 years. Consider environments with 4 and 50 times that many users. How many John Smiths do you have? How many Luana Garcia's do you have? How many people with the name Cheng Shao Yu do you have? How many Maximilian Zimmermann? SAM Names can have complete, some, or no relation to the person's real name. The best part, it is easier to do uniqueness and not have some people with names that look right and some that are hacked to death. I much prefer seeing first letter and x letters of last name to get to 8 or 10 characters and then maybe a couple of numbers for uniqueness than trying different hodge podge combinations of first and last and maybe middle to get to a unique SAM Name. Take my name, at various points I have been b-joeric, joe, joer, joeric, joerich, joerichards,joe.richards,joseph.richards,jricha34,jrichards, richarjo,richjoe, etc... Looking at all of those, only one seems easily scalable to me in a company with many userids. Even if you have a small company of 50,000 people, how much turnover do you have? You don't just want to have all people at one moment in time to have unique IDs. You want people to always have a unique ID at a company. That way if joer leaves, some other joer doesn't come into being. This is important from the standpoint of old security logs and plus, joer might come back, would be nice if he got his old userid back. You go back to one of the companies I used to work for and many people, thousands probably, will know exactly who jricha34 is. There will never be another user jricha34 on that corporate network that isn't me. Now that is uniqueness. Uniquely identifying people has implications on security. Wow, this went all over the place... Short answer is No. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, February 20, 2005 8:14 AM To: [email protected] Subject: [ActiveDir] samAccountName attribute length Hi All, I know this might sound a bit crazy but is it possible to turn off the limitation of 20 character limit for the samAccountName attribute. I understand the 20 character limit for downlevel clients authentication but I will never have downlevel clients authenticating against AD 2003. I looked in the schema master and the attribute max length is 256. When I dcpromo'd the domain I didn't choose pre-compat mode because windows 2000 and above machines are going to be in the domain. -- Thank you, Steve Schofield Microsoft MVP - ASP/ASP.NET ASPInsider Member - MCP http://www.orcsweb.com/ Powerful Web Hosting Solutions #1 in Service and Support List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
