| 
			
			 | 
		#1 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
			
			
			Доступ к DAx 4.0 из другой подсети
			 
			
			Доброго времени суток 
		
		
		
		
		
		
		
	Подобный вопрос поднимался здесь и ранее, но ответа, имхо так и не прозвучало. Дано: 1. Две подсети, обе с AD сеть1 и сеть2, доступ друг к другу не имеющие 2. На стыке поднимается фейковая сеть (напри 192.168.x.0/30, всего 2 адреса .1 и .2 ) 3. Настраивается маршрутизация и маппинг Аксаптовского порта (адреса .1 и, например, порта 2714) внутрь сети1 Задача: Получить клиентом DAx4.0 sp2 из сети2 доступ к аосу сети1 (т.е. фактически к фековому адресу 192.168.x.1) Проблема. Открытие (и маппинг) всех необходимых портов (или настройкой маршрутизации) и включение станции сети2 в домен сети1 решает проблему, но это решение неприемлимо ибо клиент должен оставаться в домене сети2. Ни один из предложенных здесь вариантов не работает. В плоской сети данная проблема обходиться изменением сидов в таблицах UserInfo и SysBCProxyUserAccount.(в первой пишется сид локального юзера, во второй сид сопоставленного пользователя AD) Кто-нибудь сталкивался с проблемой доступа к Аксапте из другой сети и другого домена? Ошибка стандартная: "Cannot establish connection"  | 
| 
	
 | 
| 
			
			 | 
		#2 | 
| 
			
			 Administrator 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Нет, по другому данная проблема не решается (если не считать возможность работы из сети2 по веб-порталу к сети1). 
				__________________ 
		
		
		
		
	Возможно сделать все. Вопрос времени  | 
| 
	
 | 
| 
			
			 | 
		#3 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 Цитата: 
	
Или обязательно для доступа к Аксапте иметь один forest?  | 
| 
	
 | 
| 
			
			 | 
		#4 | 
| 
			
			 Administrator 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Хм... не пробовал. По логике - может и прокатит. А может потребуется аос запускать от имени пользователя из корневого домена. (Допустим, у нас такая схема: корень-домен1 и корень-домен2. Тогда чтобы достучаться из пользователю из домена2 до аоса из домена1 может (надо проверить) потребоваться аос запускать от имени учетной записи из корневого домена).
		 
		
		
		
		
		
		
			
				__________________ 
		
		
		
		
	Возможно сделать все. Вопрос времени  | 
| 
	
 | 
| 
			
			 | 
		#5 | 
| 
			
			 Участник 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Самое обидное, что даже доверить друг другу домены никто не позволит. 
		
		
		
		
		
		
		
	Ужасно упрямая и негибкая система авторизации. Будем обходиться терминалами, увеличивая стоимость владения - снижение которой так часто декларируется Микрософт.  | 
| 
	
 | 
| 
			
			 | 
		#6 | 
| 
			
			 MCTS 
		
			
	 | 
	
	
	
		
		
		
		 
			
			Думаю тогда без вариантов, поскольку даже для доступа внешних пользователей через Enterprise Portal предполагается организация доверительных отношений между доменами: Организация доступа внешних веб-пользователей к DAX 4.0
		 
		
		
		
		
		
		
		
	 | 
| 
	
 |