Internal server error 43531

Same problem with ADC version 13.0 58.32. Change to IP was successful.
Thank you!

This solved it for us
https://it-feed.de/citrix-adc-internal-server-error-43531-nach-upgrade-auf-71-40/

Upgraded from 13.0.64x to 13.0.82x
Fix: citrix removed expression that we were using. Changed below and all was good.
Depreciated Expression:
REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS
New Expression:
HTTP.REQ.HEADER.CONTAINS(Citrix Reciever)

Thanks for the details. We encountered today in our environment and going to attempt this. Thanks Terence Luk for teh blog 🙂

Источник

Проблема

Есть NetScaler NS12.1: Build 48.13.nc.
После настройки связки Store Front + Netscaler Gateway пользователь не может залогиниться. После аутентификации пользователя видим:

Статьи нам говорят, что проблема связана либо с DNS — https://support.citrix.com/article/CTX207033, либо с сертификатами на Store Front.
Однако, имя сервера Store Front нормально резолвится и пингуется из shell, как просто имя хоста, так и FQDN, а доступ к Store Front осуществляется по HTTP (без SSL).
В логе /var/log/ns.log при входе пользователя ошибка — “Ica mode status is not okay”:

На сервере StoreFront адрес выглядит как: http://_hostname(not_fqdn)_/Ctirix/StoreName.

Причина

Даже если при конфигурировании Netscaler Gateway указывать полное FQDN-имя сервера Store Front, то при нажатии кнопки Retrive Stores визард скажет:

и поменяет имя сервера StoreFront на не-FQDN — http://_hostname(not_fqdn)_.
В результате, по непонятной причине, имя сервера StoreFront перестает нормально резолвиться во время работы (хотя из shell нормально резолвятся оба варианта имени).
Кроме того, возможны варианты: https://support.citrix.com/article/CTX235425 (галочка ICA Only в свойствах виртуального сервера Netscaler Gateway должна быть снята).
https://support.citrix.com/article/CTX216509 — поломаны маршруты.

Решение

В моем случае — чтобы все заработало, после нажатия кнопки Retrive Stores нужно исправить имя сервера Store Front на FQDN-имя.

Источник

Marius Sandbu – IT blog

Containing ramblings about Cloud, End-user computing, software defined datacenter and IT-security related information.

Troubleshooting ICA-proxy and authentication sessions NetScaler

This is a section of my latest eBook, but I figured that it could be more useful as a blog-section which people could reference if needed and also makes it easier for me to update when new stuff appers to give a simple resolution for known errors.

Cannot complete your request

After logging into the NetScaler Gateway and the enduser is redirected to the StoreFront page you get the error message “Cannot Complete your request”

You can also notice that you get an error in event viewer of the storefront server under Application and Services Logs -> Citrix Delivery Services. Where you get an error message of “None of the AG Call back service responded”

This is often the case if Storefront cannot talk back with the callback URL which is listed under Manage NetScaler Gateways à Edit NetScaler Gateway à Authentication Settings à Callback URL. Make sure that this URL is accessible from the Storefront server. If this is not possible because of network segmentation. You can deploy a dummy NetScaler Gateway VIP in the internal network.

If you notice that you have an error in Event viewer stating that “Citrix AGBasic Login request has failed”. That might be that there are different domains specified on the NetScaler session policy and under Storefront. If you have specified a domain name in Storefront under Manage Authentication à Pass-through from NetScaler Gateway à Configure trusted domains, this needs to be the same domain name in the session policy as well.

If you note that you have an error in Event viewer stating that Failed to run discovery this is most likely the case if you have not configured the use of a proper SSL certificate under the IIS administration console of the Storefront server.

Your logon has expired

If you are prompted for another authentication after logging into the NetScaler Gateway portal, when redirected to the Storefront portal, and then this error message appears.

You can also notice an error in event viewer of the storefront server under Application and Services Logs -> Citrix Delivery Services. That states, “A request was sent to service that was detected as passing through a gateway, but none of these matched the request.

This is typically the case if the NetScaler Gateway URL is configured wrongly. Since this URL needs to be the same as what the end-users are using, in case Storefront will not trust the incoming request and therefore ignore authentication attempts.

Unknown Client error 1110

This is a generic error which might occur in many different scenarios, but some key things to check to find the root cause of the issue.

· STA available on the NetScaler and marked as up? (This can be checked under NetScaler Gateway à Virtual Server à Published Applications à STA Server.

Cannot Start Desktop “COMPUTERNAME”

If you try launching an application or desktop and you get the error message cannot start Desktop/Application name after authenticating and getting the resources up

This might just be that the resource that we are trying to launch in currently unavailable or that something for instance is wrong with the VDA agents on that resource we are trying to launch.

We can also go into event viewer of Storefront to take a closer look at what kind of error is actually happening. Event viewer à Application and Services Logs -> Citrix Delivery Services. If we get an error message here stating “All the configured Secure Ticket authorities failed to respond”

This might be that we have an STA server that is down, in which Storefront tries to communicate with or that we have configured the wrong STA server under NetScaler Gateway appliances in Storefront. This can be checked under à Manage NetScaler Gateways à Edit NetScaler Gateway à Secure Ticket Authority.

Error: Login exceeds maximum allowed users

When logging in you get an error message stating that login exceeds maximum allowed users. This is typically the case if we did not place the virtual server in ICA-only mode. By default, the global AAA settings of NetScaler Gateway is set to allow maximum 5 users logging in using VPN at the same time. If we go and change the settings of the Virtual server to ICA-only mode, this error will go away.

Http/1.1 Internal Server Error 43531

After authenticating to the NetScaler Gateway portal you get a blank page with an error message stating Http/1.1 Internal Server Error 43531. This is typically the case if the Gateway cannot communicate with the Storefront web site. Which might just be a wrong URL in the session policy for instance.

Or this can also be that a client is not being applied a session policy, if we for instance have session policies in place based upon different criteria’s. If someone outside those criteria would get those error messages. The easiest way to get them access is to bind a session policy with the highest priority number with an expression of ns_true.

403 – Forbidden: Access is denied

After authenticating to the NetScaler Gateway portal, you get a default IIS error message stating “Access is denied”. This is typically the case if the session policy does not point directly to the receiver for web site on Storefront. After changing, the session policy to point to the direct URL this error message will go away.

Authentication

In case of authentication failure attempt, a user will be given a generic error message of:

There are many ways to troubleshoot authentication failures, the simplest one is using the authentication dashboard in the NetScaler UI.

Which basically list the syslog events directly into the UI. Another way is using CLI. Log into the NetScaler appliance using an SSH client, type Shell and then type cat /tmp/aaad.debug

This will in real-time list out all AAA attempts happening against the NetScaler. Now by default the NetScaler does not list out detailed information whenever a user has an expired password or if their account is disabled. However, there is a feature which we can enabled which can give more detailed information back to the end user. This feature is called Enhanced Authentication Feedback

Which enabled under NetScaler Gateway à Global Settings à Change Authentication AAA settings.

NOTE: This setting is disabled by default, because it might reveal to much information to malicious hackers which try to do a brute force attack, to get information on which users are enabled and not.

It is also important that the aaad.debug command lists out different error codes when there is a failed authentication attempt.

For instance, if a user with a disabled account tries to authenticate.

Send reject with code Rejecting with error code 4011

Citrix has made a list which describes all these error codes and the meaning of them.

4001 Invalid credentials. Catch-all error from previous versions.

4002 Login not permitted. Catch-all error from previous versions.

4003 Server timeout

4004 System error

4005 Socket error talking to authentication server

4006 Bad (format) user passed to nsaaad

4007 Bad (format) password passed to nsaaad

4008 Password mismatch (when entering new password)

4009 User not found

4010 Restricted login hours

4011 Account disabled

4012 Password expired

4013 No dial-in permission (RADIUS specific)

4014 Error changing password

4015 Account locked

Now if a user tries to authenticate but is not bound to an authentication policy, for instance if we have multiple authentication policy for different groups, network segments and someone which fall outside of those policies try to authenticate they are presented with this error message.

The simplest way to fix this is to either define ns_true authentication policy which handles all other authentication attempts.

Now if an end-user tries to authenticate to start a Citrix Receiver session and is presented with this error message

This is typically the case if there is a session policy bound to the user which has a default authorization policy of DENY, this might be intended but if not, we should change it to ALLOW.

Источник

Ошибка Internal Server Error: что это и как с ней бороться

Достаточно часто владельцы хостингов мучаются из-за постоянного возникновения сообщения об ошибке 500 (Internal Server Error). Она, как это называется, многим попросту отравляет жизнь. Сейчас мы попробуем кратко разобраться в сути самой ситуации и посмотрим, как же можно избавиться от появления ошибки в будущем.

Ошибка Internal Server Error: что это?

Итак, начнем, пожалуй, с самого значения этого словосочетания. В системе (каталоге) ошибок Windows (и не только) есть ошибка под номером 500, отвечающая компьютерному термину Internal Server Error. Перевод этого словосочетания означает внутреннюю ошибку сервера, связанную со статусом протокола HTTP.

По сути, ошибка означает, что программное обеспечение сервера либо не работает, либо работает, но один или несколько его компонентов дают сбои в виде отказа на клиентские запросы, например, поисковой системы или интернет-браузера.

Причины возникновения ошибки

Говоря об ошибке Internal Server Error в самом широком понимании, стоит учитывать, что возникать она может на множестве сайтов или ресурсов, написанных с помощью совершенно разных CMS. Тут, кстати, нужно разграничить причины ее возникновения.

Очень часто такая ситуация может наблюдаться на сайтах типа WordPress, OpenCart, Joomla и др. Если же структуры управления, подобные WordPress, при построении сайта не используются, возможно, причина кроется в том, что на самом хостинге возникают сбои при подключении неправильных PHP-расширений, или сайт после запроса возвращает некорректные HTTP-заголовки, которые не могут быть распознаны вашим сервером.

Не менее распространенной причиной возникновения ошибки Internal Server Error можно назвать отсутствие корректных прав доступа. Так, например, если на PHP файлы скриптов, которые размещены на хостинге, имеют права доступа 777, очень может быть, что их исполнение попросту блокируется сервером, вследствие чего и выдается сообщение об ошибке.

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

В некоторых случаях ошибка Internal Server Error может появляться, когда на хостинге наблюдается превышение лимита используемой памяти. Попросту говоря, скрипт для исполнения требует больше положенного, а ведь такой лимит устанавливается не только на PHP, зачастую действуют ограничения по потреблению ресурсов всеми исполняемыми скриптами.

Наконец, одна из самых распространенных ситуаций возникновения ошибки Internal Server Error – это содержание некорректных директив в файле .htaccess (кстати, при работе с движком WordPress это проявляется наиболее часто). Вот теперь мы вплотную подошли к поиску решения для каждой конкретной ситуации.

Ошибка Internal Server Error: как исправить простейшими способами

Для начала посмотрим, что можно сделать при обнаружении неправильных прав доступа. В данном случае права доступа 777 позволяют редактировать содержимое абсолютно всем, что, несомненно, сказывается на безопасности. В такой ситуации необходимо их изменить, применив к папкам значение 755, к файлам скриптов – 600, а ко всем стальным файлам данных – 644.

При слишком долгой работе исполняемого скрипта можно попробовать увеличить время ожидания, правда, тут есть одна загвоздка. Такое решение может сработать на выделенном сервере или VPS (Virtual Private Server), а в случае виртуального хостинга никакого эффекта не будет.

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

Теперь несколько слов о файле .htaccess. Дело в том, что он предполагает использование очень строгого синтаксиса, если при проведении настроек были допущены ошибки или некоторые неточности, избежать появления ошибки Internal Server Error не удастся. Тут нужно поступить следующим образом. Для начала нужно проверить наличие самого файла в корневой директории сайта, после чего, сделав его резервную копию, удалить целиком и полностью. Если после такой процедуры сайт снова станет работоспособным, значит проблема именно в файле .htaccess, который придется проверить на наличие ошибок в синтаксисе.

Проблемы с движком WordPress

С WordPress дело обстоит хуже. Дело в том, что этот движок способен перезаписывать оригинальный файл .htaccess, отвечающий за управление доступом к файлам и папкам хостинга, а ведь оригинальный файл должен создаваться всего один раз, и тем более не в WordPress!

Самым простым способом исправления такой ситуации является отключение темы WordPress и использование вместо нее любой другой. Если ошибка исчезла, дело именно в самой теме, если нет – нужно поэтапно отключать плагины WordPress и проверять, какой из них влияет на работоспособность.

В некоторых случаях может потребоваться обновить WordPress до последней версии и отключить функцию перезаписи файла. Для начала скачиваем на компьютерный терминал оригинальный файл .htaccess, затем входим на сайте в папку по пути /wp-admin/includes/ с последующей загрузкой файла misc.php, который необходимо открыть, скажем, в стандартном «Блокноте» (или любом другом текстовом редакторе) и найти строку функции «function save_mod_rewrite_rules». Теперь в самой функции переходим к строке «return insert_with_markers( $htaccess_file, ‘WordPress’, $rules );» и заменяем ее на «return true;» (естественно, все команды прописываются без кавычек). Остается только сохранить изменения и загрузить новый файл на хостинг с заменой старого файла misc.php.

Недостатком такого метода является только то, что в данном случае отключается обновление WordPress. При подключении плагинов они работать, естественно, не будут.

Заключение

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

Источник