If it's useful, I've implemented our own RemoteUserMapper, that reimplements the header extraction as follows:-

    private String extractUserFromProxyHeader(HttpServletRequest request)
    {
        String userId = request.getHeader(this.proxyHeader);
        if (userId == null)
        {
            return null;
        }
        if (this.userIdPattern == null)
        {
            return userId.trim();
        }

        Matcher matcher = this.userIdPattern.matcher(userId);

        // If pattern matches, pull out first bracketed group, or entire matching area
        if (matcher.find())
        {
            return matcher.groupCount() > 0 ? matcher.group(1) : matcher.group();
        }

        // Couldn't match pattern
        return null;
    }

org.alfresco.web.app.servlet.DefaultRemoteUserMapper.extractUserFromProxyHeader(HttpServletRequest) should use group(1) instead of group() so that it will extract the first matching group from a regular expression, rather than the entire match.

This was fixed by the fix to ALF-2043

For retest in 3.2 sp1

Reopened in Alfresco 3.2.1 EE b 495 using Windows 2008 SP1 x64, Tomcat 6.0.18, Mysql 5.1.34, JDK 6u16 x64.

Used the following settings:
authentication.chain=external1:external,alfrescoNtlm1:alfrescoNtlm
external.authentication.proxyUserName=
external.authentication.proxyHeader=x-user
external.authentication.userIdPattern=^(admin)

We can successully login with such headers as "123Adminsd", "345" and any other. The userIdPattern doesn't block user login and doesn't strip headers like "admin-somethingelse". We login with exactly the same username as set in the header.

For retest in 3.3E build 27

Successfully validated in ALfresco 3.3 EE b 27 using Windows 2003 SP1 x64, Tomcat 6.0.26, Mysql 5.1.34, JDK 6u16 x64.