Slipeer

1. Если у Вас openldap - для диагностики можно в логах посмотреть что и как он ищет
2. Попробуйте просто указать base dn "dc=ldap,dc=ru"
3. Проверьте, что у указанного пользователя (Manager DN, под которым в LDAP работает jenkins есть доступ к "dc=ldap,dc=ru", например выполните от него ldapsearch со scope subtree и basedn "dc=ldap,dc=ru",)

Если на входе XML правильней всего воспользоваться соответствующим парсером.
Вот здесь хорошие примеры
На выходе из парсера будет хэш - останется поискать в нём ip адреса.

Ну а если неправильно и по-быстрому:

while (defined(my $line = $fh->getline())) {
while ( $line =~ m/(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})<\/ip>/g) {
print "$1\n";
}
}

Насколько вижу по скриншотам:
1) У Вас 2008 или новее
2) Вы включили категорию аудита "object access"

начиная с 2008 ввели подкатегории аудита (они у Вас в "Advanced Audit Policy Configuration")
Почитать можно здесь.
Настройте только необходимую Вам подкатегорию.

Версия qemu-img какая?
Быть может эта информация Вам поможет. Там пишут, что для qemu-img новее 1.1.1 достаточно переименоват расширение в vhd.
Ну или преобразование vhdx в vhd на 2012-м.

Перловые константы на самом деле - функции, возвращающие нужные значения.
Соответственно для вызова функции по имени:

use WWW::Curl;
use WWW::Curl::Easy;
use Data::Dumper;

my %opts = (
    CURLOPT_URL => 'http://wikipedia.org',
    CURLOPT_CONNECTTIMEOUT => 30
);

sub curl_func {
    my ($curlOptions) = @_;
    my $ch = new WWW::Curl::Easy();
    while (my ($key, $value) = each %$curlOptions) {
        $ch->setopt(&{$key}(), $value);
    }
    # ...
}

curl_func(\%opts);

Насколько понял - речь идёт о NAT у провайдера. Тогда ответ - никак. Как вариант - такие провайдеры обычно отдельно продают балую статику (Может выйти дешевле и менее геморройно чем с тоннелем через VPS)

Еще имею доступ к VPS, на котором можно сколько угодно портов открывать.

Тут вариантов много: проброс порта по ssh, VPN тоннель и Port Forwarding на VPS, VPN до VPS и проксирование на VPS.
Но все эти варианты сложнее покупки белой статики у провайдера и потребуют дополнительной поддержки.

Во-первых - уточните, что у Вас используется в качестве LDAP сервера (реализаций достаточно много)
Во-вторых посмотрите схему LDAP сервера для этих атрибутов.
Обычно manager заполняется на объекте пользователя и задаёт DN его начальника.
Обычно secretary заполняется на объекте пользователя и задаёт DN его секретаря.
Если будете заполнять эти атрибуты каким-либо необычным способом - в дальнейшем при интеграции с LDAP новых продуктов могут возникнуть проблемы.
Если требуются атрибуты и в LDAP нет полностью подходящих - правильнее подготовить расширение схемы (или найти уже готовое).

В этом есть даже некоторые плюсы:
Можно будет изолировать от production среды
При переносе в production вылезет большинство имеющих место "гвоздями прибитых" настроек
Можно будет дать волю разработчикам/тестерам в тестовом домене (за исключением схем, если они в одном лесу)
Можно ставить эксперименты над DNS

owncloud - решает всё, кроме доступа по smb (но можно по webdav подключиться)
И совершенно бесплатно.

Аналоги есть. В том числе и платные (например у Cisco). Но из свободного openfire лично мне больше всего подошёл.

Пробовал разворачивать openfire все устраивает, но по неизвестным причинам спустя некоторое время работы просто слетает (то в админку не зайти, то пользователи в оффлайне)

Много пользователей? Ростеры по группам в AD ?
Там настройки кэша по-умолчанию очень неподходящие.
Почитайте: https://community.igniterealtime.org/docs/DOC-1673
Там в админке в Server->Server manager->Cache Summary видно как кэш используется.
Если один из кэшей для AD забит на 100% и имеет малый процент попадания запросов в кэш - у меня были очень похожие на ваши проблемы.

Пароли не перенести никак (на самом деле есть один способ, но это сложно и для тестирования неоправданно).
Для переноса объектов пользователей вместе с флагами попробуйте экспортировать их вот так:

ldifde -f Exportuser.ldf -s kontora -d "dc=kontora,dc=ru" -p subtree -r "(&(objectCategory=person)(objectClass=User)(givenname=*))" -l "cn,givenName,objectclass,samAccountName,userAccountControl"

В атрибуте userAccountControl хранится информация о заблокированности пользователя в том числе.
Или для включения уже проимпортированных пользователей можно попробовать что-нибудь вроде:

Get-ADUser -LDAPFilter "(&(objectCategory=person)(objectClass=User)(userAccountControl:1.2.840.113556.1.4.803:=2))" | Enable-ADAccount