Расскажите как, а то как бы не оказалось что это решение похожее на то что было - работающее только при случайном стечении обстоятельств.

Очень просто: в init-методе я ставлю статически флаг на true, а в doPost опрашиваю значение этого флага, при true заставляю юзера перелогиниваться в первом окне и ставлю флаг на false
Но теперь юзеры вдруг недовольны, оказывается, они все-таки хотят работать в двух окнах и утверждают, что изначальная проблема возникает и при одном окне, чего я себе представить не могу.

"Статика" для Веба имеет свои особенности, поэтому лучше всего статику держать в базе (хотя и там будут свои проблемы).

А что может произойти?

всё что угодно, что на первый взгляд объяснить довольно тяжело.
С Явой под вебом я не работал, но думаю принципы остаются такими же.
http://www.coderanch.com/t/362275/Servlets/java/static-avoided-web-app
http://stackoverflow.com/questions/8919095/lifetime-of-asp-net-static-variable
http://blog.aggregatedintelligence.com/2009/01/static-variables-and-their-implic...
http://stackoverflow.com/questions/14154892/scope-of-static-variable-in-multi-us...

У меня проблемка в том, что на другой машине уже не работает
Связано ли это с этой статической переменной? Чота я сомневаюсь, честно говоря. Режим секьюрити поставил и там, и там, какие-то переменные окружения или параметры старта RMI штоле повлияли? Теряюсь в догадках.

Рука-лицо.
Если вы и правда меняете статическую переменную, то таким макаром залогиниться у вас сможет один-единственный человек. Вообще. Даже с 100500 компьютеров с разными сессиями. До тех пор пока томкат не перегрузит полностью все ваше веб-приложение (надо перегрузить класс).
Один человек логинится, потом логаутится. А второй раз залогинится не сможет. Переменная-то уже установлена.

Хм. А я думал, ее глобальность распространяется только на конкретный сервлет. Разве нет?
Тогда статику можно убрать. Или то же самое сделать с аплетом и он будет сингл-тоном, нет?
Вы же вроде мне и другому товарищу говорили про многопоточность и что разные ява-машины и даже разные слои никак друг с другом не связаны.

Правильный ответ - на все классы, загруженные одним ClassLoader-ом. В простом случае обычного ява-приложения можно все классы считать существующими в одном экземпляре. Для веб-приложения внутри приложения все классы загружены один раз. Чтобы вас не путать дальше рассказывать не буду :)
На конкретный сервлет будут "распространятся" поля объекта. Хотите что-то сохранить между вызовами - сохраняйте в поле объекта. Например, вы хотите посчитать сколько раз на сервлет логинились. private int loginCounter и при каждом логине увеличиваем на единицу.

Апплет у вас во-первых не синглтон, во-вторых он может загружаться разными (процессами) JVM и тогда два инстанса вообще ничего не знают друг о друге.

JVM друг с другом не связаны. А вот что вы сейчас "слоями" назвали я не знаю.

Ну, то есть просто надо убрать static. Я поначалу так и думал, но потом решил все это verschlimmbessern.

Но, может быть, его можно сделать таким путем синглтоном?
А то как-то странно получается, все апплеты друг с дружкой незнакомы и пролетают мимо, как непредставленные друг другу англичане, зато один сервлет может изгадить малину всем другим сервлетам :)
Впрочем, да, понимаю, в одном случае один и тот же веб-сервер, в другом - разные ява-машины.

Ну, Вы в начале что-то такое говорили. Вот, нашел:

Не-а. Убрав static вы сделаете поиск ошибки "а почему мой клиент то может залогинится то нет" очень увлекательным для тех, кто будет потом пытаться сделать что-то работающее их этого непотребства.
Смотрите. Вообще контейнер создает одну копию вашего сервлета. Т.е. установив флаг на "уже залогинился" даже в поле объекта, и нигде его не возвращая в "разлогинился", вы приходите к тому что у вас было со статическим полем. За одним исключением. Сервлет можно уничтожить и заново пронициализировать. Не надо перегружать всё приложение. Так что да, решение с флагом в поле объекта чем-то лучше чем со статическим полем.
Но. Вообще контейнеры могут создавать и несколько копий сервлета. Особенно если (как это сделано у вас) сервлет объявлен implements SingleThreadModel. Сколько копий - вы повлиять не можете. Какая копия будет обрабатывать какой запрос - тоже. И тут вы можете получить любое поведение да еще и меняющееся от версии контейнера. Поставите новую версию томката, или перейдете на JBoss, WAS еще что-то и ваш сервлет станет работать саавсем по другому.
Вы понимаете к чему вы придете если у вас будут несколько копий сервлета по очереди обрабатывающие запросы? (не каждая копия - свою сессию, а именно по очереди приходящих запросов).

Если запихнете два раза один и тот же класс сервлета в два разных веб-приложения получите полностью независимые друг от друга классы. А можно и тут их связать :) Если архив с классом сервлета запихать не в WAR а в каталог с библиотеками самого томката :)

Угу. Класслоадерами. Классы загруженные разными класслоадерами друг о друге не знают.

Какой ужос
Земную жисть пройдя до середины, я оказался в сумрачном лесу.
Странно, что для такой в общем-то обычной и достаточно стандартной проблемы до сих пор нет никакого стандартного решения.
К моему счастью, наши юзеры, похоже, сильно недовольны запретом двух окон и я пока имплементирую другое решение, не связанное с количеством окон. Тем более, что они утверждают, что изначальная проблема проявляется и при одном окне.

Нда-с. Стандартное решение (появившееся вместе со спецификациуй сервлетов 1.1 в чтобы не соврать... 98-м что-ли году) - работать с сессиями, передав аутентификацию пользователя контейнеру и уничтожать сессию при неактивности или логауте.

Но это ведь тоже не решение проблемы, как мы видим, если сессия может делиться "почкованием".

Может быть что угодно. Можно писать свои фильтры, "клапаны", контексты и менеджеры. Но это не значит что это надо делать. В нормальных проектах никаких "делений" сессий не делают.
Ну и я пока что в вашем коде нигде не видел чтобы у вас сессия "почкованием" делилась.

Я имел в виду, что она привязана к IP, сколько окон на нем ни запускай.

Если это действительно так, то это в коде вашего апплета (скорее всего). Сами себе топором ножки отрубили и жалуетесь что ходить не можете. Бывает.
Посмотрите, может в вашем коде где-то используется CookieManager?

Проверил, не используется.

Идеи у меня закончились. Не меняя ни контекста, ни менеджера сессий на стороне сервлета и не используя куки на стороне апплета забабахать на томкате сессию для одного IP...
Наверняка ведь какое-то изящное в своей тупизне решение применено :) Но не могу угадать какое.
О, как можно проверить где намудрили - на стороне клиента или сервлета. Вызовите URL вашего сервлета (где ICM6/servlet/ndServlet) просто из адресной строки браузера (желательно другого, не IE, в котором у вас апплет). И посмотрите что у вас в doPost в логи упадет - какое там ID у сессии будет.
А, не выйдет. Надо в doGet скопировать код для отладки - потому как doGet вызовется.
Будет то же самое ID что и у апплета - значит где-то на сервере все же изменен стандартный менеджер сессий. Если другой ID - ну тогда оригинальное решение спрятано в коде апплета.
Посмотрите еще, на всякий случай - у вас никакой класс не имплементирует интерфейс org.apache.catalina.Manager?

Нет, не имплементирует.