I migrated an Azure DevOps Server (née TFS) to a different physical machine, and while most stuff seems to work, one thing that didn't survive is user identities, because the old machine was in a different domain (in the NT sense).
Suppose a project has a team of OLDDOMAIN\Dan and OLDDOMAIN\Sally — is there some script I can use to add NEWDOMAIN\Dan and NEWDOMAIN\Sally to the same team? Failing that, is there a way to list all project teams and/or recursively list all permissions?
Here's our network:
In this example, we have:
el-1, which runs an OpenVPN server, providing the network 10.26/24 (and acting as a gateway at 10.26.0.1). In the VLAN, it also has the address 192.168.50.51.master, which is more heavily firewalled. In the VLAN, it has 192.168.50.41.I've already accomplished setting up an OpenVPN server, and those clients can connect and reach (otherwise firewalled) ports on el-1 itself. Now I want those clients to somehow also access master through the same VPN, probably using the VLAN.
If I RDP into el-1, I can use the VLAN address of 192.168.50.41 to reach ports on master that aren't publicly open. So the VLAN does appear to work, and the firewall doesn't appear to be a problem at that stage.
Just for the sake of it, a client config:
client
dev tun
proto udp
remote (the server) 11194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert someUsername.crt
key someUsername.key
ns-cert-type server
cipher AES-256-CBC
comp-lzo
verb 3
Here's what the server config used to look like:
local 0.0.0.0
#we use a non-default port 11194
port 11194
proto udp
dev tun
client-config-dir ccd
ccd-exclusive
ca ..//easy-rsa//keys//ca.crt
cert ..//easy-rsa//keys//server.crt
key ..//easy-rsa//keys//server.key
dh ..//easy-rsa//keys//dh2048.pem
server 10.26.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 60
cipher AES-256-CBC
comp-lzo
max-clients 20
persist-key
persist-tun
status ..//log//openvpn-status.log
verb 3
(I know comp-lzo and ns-cert-type are deprecated; that's a different matter.)
I then basically figured from the docs that server is a shorthand that may not accomplish this more complex scenario? So I broke that up as follows:
local 0.0.0.0
#we use a non-default port 11194
port 11194
proto udp
dev tun
client-config-dir ccd
ccd-exclusive
ca ..//easy-rsa//keys//ca.crt
cert ..//easy-rsa//keys//server.crt
key ..//easy-rsa//keys//server.key
dh ..//easy-rsa//keys//dh2048.pem
mode server
tls-server
ifconfig-pool-persist ipp.txt
keepalive 10 60
cipher AES-256-CBC
comp-lzo
max-clients 20
persist-key
persist-tun
status ..//log//openvpn-status.log
verb 3
# formerly the server directive
topology subnet
push "topology subnet"
ifconfig 10.26.0.1 255.255.255.0
ifconfig-pool 10.26.0.2 10.26.0.253
push "route-gateway 10.26.0.1"
I think that's supposed to be roughly equivalent, except now the topology is subnet, when it was net30 before). I then added the following:
# VLAN
push "route 192.168.50.0 255.255.255.0 10.26.0.1 1"
And the result looks right on the client! From the client-side OpenVPN log:
2020-04-02 10:39:27.067370 MANAGEMENT: >STATE:1585816767,ASSIGN_IP,,10.26.0.16,,,,
2020-04-02 10:39:27.067396 /sbin/ifconfig utun7 delete
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
2020-04-02 10:39:27.072671 NOTE: Tried to delete pre-existing tun/tap instance -- No Problem if failure
2020-04-02 10:39:27.072721 /sbin/ifconfig utun7 10.26.0.16 10.26.0.16 netmask 255.255.255.0 mtu 1500 up
2020-04-02 10:39:27.076570 /sbin/route add -net 10.26.0.0 10.26.0.16 255.255.255.0
add net 10.26.0.0: gateway 10.26.0.16
2020-04-02 10:39:27.082300 MANAGEMENT: >STATE:1585816767,ADD_ROUTES,,,,,,
2020-04-02 10:39:27.082345 /sbin/route add -net 192.168.50.0 10.26.0.1 255.255.255.0
add net 192.168.50.0: gateway 10.26.0.1
And the routes:
~> netstat -nr
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.2.234 UGSc en0
10.26/24 10.26.0.16 UGSc utun7
10.26.0.16 10.26.0.16 UH utun7
127 127.0.0.1 UCS lo0
127.0.0.1 127.0.0.1 UH lo0
169.254 link#4 UCS en0 !
[..]
192.168.50 10.26.0.1 UGSc utun7
224.0.0/4 link#4 UmCS en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI en0
255.255.255.255/32 link#4 UCS en0 !
So that looks exactly correct, right? I should now be able to reach a port on 192.168.50.41 through the VPN at 10.26.0.1 (on utun7).
But it's filtered. I've temporarily disabled firewalls on both servers (which shouldn't be the reason); still filtered.
So,
traceroute just gets stuck:
~> traceroute -n 192.168.50.41
traceroute to 192.168.50.41 (192.168.50.41), 64 hops max, 52 byte packets
1 * * *
2 * * *
3 * * *
We're running ejabberd 17.07 on an Ubuntu 17.10 VM, and authenticating against an Active Directory on Windows Server 2012 R2.
This mostly works, but several times a day, logging in fails. It appears ejabberd runs into a timeout trying to look up information from the LDAP server. Restarting the daemon like so:
sudo ejabberdctl restart
...obviously kicks everyone out, but afterwards, logging in immediately works again.
I see no apparent related logs on the Windows end (I've looked in the Security and Directory Service logs), suggesting authentication wasn't actually attempd. However, on the ejabberd side, logs like this one sometimes show up:
2018-04-30 13:08:05.560 [error] <0.587.0>@eldap_pool:do_request:75 LDAP request failed: timed out
And when relaunching the server, this one:
2018-04-30 14:58:35.524 [error] <0.793.0>@eldap_pool:do_request:77 LDAP request failed: eldap:search([[{base,<<"ou=Mitarbeiter,dc=…,dc=local">>},{filter,{and,[{equalityMatch,{'AttributeValueAssertion',<<"objectCategory">>,<<"group">>}},{equalityMatch,{'AttributeValueAssertion',<<"cn">>,<<"Alle Mitarbeiter">>}}]}},{timeout,5},{deref_aliases,never},{attributes,[<<"sAMAccountName">>]}]])
Reason: {shutdown,{gen_fsm,sync_send_event,[<0.462.0>,{search,{eldap_search,wholeSubtree,<<"ou=Mitarbeiter,dc=trenz,dc=local">>,{and,[{equalityMatch,{'AttributeValueAssertion',<<"objectCategory">>,<<"group">>}},{equalityMatch,{'AttributeValueAssertion',<<"cn">>,<<"Alle Mitarbeiter">>}}]},0,[<<"sAMAccountName">>],false,neverDerefAliases,5}},110500]}}
Notice the "reason: shutdown" part.
Cursory searches suggest this is related to TCP keepalive settings, namely: it appears ejabberd expects the LDAP connection to be left open, whereas Active Directory (silently) expects the request to be a single transaction. Is my understanding of this roughly correct?
If so, short of patching the ejabberd binary like suggested here and in other places, what can I do?
(I've also tried, to no avail, to tweak keepalive settings on the Linux machine.)
I have a DeLock-branded, Si3132-based eSATA ExpressCard in my MacBook Pro, with the com.SiliconImage.driver.Si3132r5 driver 1.5.16 on 10.5.7.
Every now and then, it apparently decides to go nuts. All I/O to the external drive will be stalled for a few seconds, then continues, then stalls again, and so on. This has appeared a while ago, possibly with the 10.5.5 update. It appears to correspond to a system log message:
4/25/09 7:09:16 PM kernel SCSIPressurePathManager: new active path available, checking, loops = 0
And sure enough, 1) I know the driver works through the SCSI system (i.e., drives are faked as external SCSI ones, not SATA ones), and 2) the most useful Google result I could find has to do with ExpressCards. Other results suggest different drivers, but so far I've only found rebadged versions of SI's 1.1.9 driver (by Sonnet and by Rosewill), which exhibits the same problem. I assume this is some sort of caching bug.
One thing I have yet to try is to install 10.5.4's SCSI-related kernel extensions.
The stalling makes the card virtually useless, as performance via USB runs circles around this.
Update: as of 10.6.1 (10B504) / 1.1.11, this is still occurring.