Posts Tagged ‘security’

NSD and OpenDNSSEC under FreeBSD 10 [Part 5: SafeNet HSM]

Wednesday, May 18th, 2016

This is the fifth part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

This time we’re going to integrate proper hardware HSM support in our setup — a pair of SafeNet Network HSMs (aka Luna SA).

Here is how our updated installation diagram looks like:

2016051701

Before we jump into technical details there are a couple of assumptions:

— I assume that HSMs are already configured and partitioned. HSM installation is outside of scope of this guide since it’s a lengthy and pretty time consuming process which has nothing to do with OpenDNSSEC. It also involves a big chunk of work to be done on the access federation field (different teams accessing different partitions with different PEDs or passwords). SafeNet HSM’s documentation is quite solid though, so make sure this part is completed. In our setup, both HSMs run the latest software 6.2.0-15 and there is one partition created on both units called TEST. TEST partition is activated and we’re going to create High Availability group, add both HSMs to the HA group and allow NS-SIGN to access it;

— As you might have noticed, I decided to leave ZSKs to be handled by SoftHSM. One of the things that you’ll have to keep an eye on with network HSMs is the HDD space. The way it works with SafeNet is that you have an appliance with some fixed amount of disk space (let’s say 2MB). Then you create partitions and allocate space out of total amount for each partition (by default it’s equal distribution). So let’s assume we created five partitions 417274 bytes each. Normally, storing a pair of public/private key consumes very little, but with OpenDNSSEC we’re talking about a number of domains each storing a pair of public/private keys for both KSK and ZSK. It’s very important to understand how far you can go, so you’re not surprised after several years when you discover that you run out of space.

Let’s do some basic math: one domain, with both ZSK (1024) and KSK (2048) stored on HSM, will consume 2768 bytes, so with 417274 bytes partition you should be able to handle ~150 domains. However, during ZSK or KSK rollover, another pair will be temporarily created, and although ZSK/KSK rollover shouldn’t happen at the same time and OpenDNSSEC will purge expired keys after the rollover is completed, you’ll have to consider extra 2768 bytes per domain (for a period of time defined in <Purge> stanza in kasp.xml), which leaves you 75 domains. As you can see this isn’t much. That’s why I decided to keep SoftHSM for ZSKs to save some HSM space (which is not cheap to say the least!).

One of the disadvantages of keeping both storage engines is that you’ll have one more dependency to worry about should you consider to upgrade (for example to SoftHSM2), hence the choice is yours. Another option would be to store private keys in HSM and leave public keys aside (<SkipPublicKey/> option under conf.xml), but I’ve read that it’s very much dependent on the HSM provider and could lead to unexpected results. And one more option would be to use <ShareKeys/> under kasp.xml — that way you can share the same key for multiple domains.

(more…)

How to configure vLAG on a Brocade VDX 6740T-1G switch to work with SafeNet Network HSM

Tuesday, January 26th, 2016

Caution! I deleted my previous post on how to configure vLAG on Brocade VDX 6740T-1G switch to work with SafeNet Network HSM because actually it didn’t work as it should. If you get a cached version somewhere please disregard it.

I have no idea how I managed to get bonding to operate in round-robin mode on SafeNet Network HSM:

  1. [hsm-node-1] lunash:>network interface bonding show
  2.  
  3. ———————————————————–
  4. Ethernet Channel Bonding Driver: v3.4.0-2 (October 7, 2008)
  5.  
  6. Bonding Mode: load balancing (round-robin)

Because once the appliance was rebooted the bonding mode has changed to active-backup and the whole story with LAGs became irrelevant. The primary interface started flapping again and the only way to stabilize connectivity to HSM was to disable the slave interface.

  1. [hsm-node-1] lunash:>network interface bonding show
  2.  
  3. ———————————————————–
  4. Ethernet Channel Bonding Driver: v3.4.0-2 (October 7, 2008)
  5.  
  6. Bonding Mode: fault-tolerance (active-backup)

So, back to the original subject of the post: how do you configure a LAG on Brocade switch to work with SafeNet Network HSM? The answer is — you don’t. In fault-tolerance bonding mode, when one interface is active and another one is backup (read passive), you don’t create any LAGs on the switch. All you have to do is to bring both interfaces to switchport mode access mode and ensure that VLAN and speed settings are identical. Here is how our switch config looks like:

  1. !
  2. interface TenGigabitEthernet 12/0/2
  3.  speed 1000
  4.  description -=HSM-NODE-1:ETH0=-
  5.  switchport
  6.  switchport mode access
  7.  switchport access vlan 12
  8.  spanning-tree shutdown
  9.  no fabric isl enable
  10.  no fabric trunk enable
  11.  no shutdown
  12. !
  13. interface TenGigabitEthernet 13/0/2
  14.  speed 1000
  15.  description -=HSM-NODE-1:ETH1=-
  16.  switchport
  17.  switchport mode access
  18.  switchport access vlan 12
  19.  spanning-tree shutdown
  20.  no fabric isl enable
  21.  no fabric trunk enable
  22.  no shutdown
  23. !

Now, you certainly lose link aggregation and load balancing functionalities, because only one interface will be passing traffic at a time. The slave interface comes into play only if the primary interface is down. We’re still good though when it comes to redundancy — you can disconnect the cable from ETH0 without any impact on connectivity.

On a HSM side, you don’t have many options so you follow the standard procedure: assign the IP address to the bond (network interface bonding config -ip x.x.x.x -netmask y.y.y.y -gateway z.z.z.z) and bring it up (network interface bonding enable).

To check the status:

  1. [hsm-node-1] lunash:>network interface bonding show
  2.  
  3. ———————————————————–
  4. Ethernet Channel Bonding Driver: v3.4.0-2 (October 7, 2008)
  5.  
  6. Bonding Mode: fault-tolerance (active-backup)
  7. Primary Slave: eth0 (primary_reselect failure)
  8. Currently Active Slave: eth1
  9. MII Status: up
  10. MII Polling Interval (ms): 100
  11. Up Delay (ms): 2000
  12. Down Delay (ms): 0
  13.  
  14. Slave Interface: eth0
  15. MII Status: up
  16. Speed: 1000 Mbps
  17. Duplex: full
  18. Link Failure Count: 0
  19. Permanent HW addr: 00:15:c4:n7:13:06
  20.  
  21. Slave Interface: eth1
  22. MII Status: up
  23. Speed: 1000 Mbps
  24. Duplex: full
  25. Link Failure Count: 0
  26. Permanent HW addr: 00:15:c4:n7:6a:34
  27. ———————————————————–
  28. ———————————————————–
  29. Status for eth0:
  30.         Link detected: yes
  31.  
  32. Status for eth1:
  33.         Link detected: yes
  34. ———————————————————–
  35.  
  36. Command Result : 0 (Success)
  1. [hsm-node-1] lunash:>status interface
  2.  
  3. bond0     Link encap:Ethernet  HWaddr 00:15:C4:N7:13:06
  4.           inet addr:192.168.100.42  Bcast:192.168.100.255  Mask:255.255.255.0
  5.           UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
  6.           RX packets:13479 errors:0 dropped:0 overruns:0 frame:0
  7.           TX packets:3183 errors:0 dropped:0 overruns:0 carrier:0
  8.           collisions:0 txqueuelen:0
  9.           RX bytes:1059045 (1.0 MiB)  TX bytes:446623 (436.1 KiB)
  10.  
  11. eth0      Link encap:Ethernet  HWaddr 00:15:C4:N7:13:06
  12.           UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  13.           RX packets:12670 errors:0 dropped:0 overruns:0 frame:0
  14.           TX packets:2082 errors:0 dropped:0 overruns:0 carrier:0
  15.           collisions:0 txqueuelen:1000
  16.           RX bytes:996811 (973.4 KiB)  TX bytes:300205 (293.1 KiB)
  17.           Interrupt:58 Memory:fb4c0000-fb4e0000
  18.  
  19. eth1      Link encap:Ethernet  HWaddr 00:15:C4:N7:6A:34
  20.           UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
  21.           RX packets:809 errors:0 dropped:0 overruns:0 frame:0
  22.           TX packets:1101 errors:0 dropped:0 overruns:0 carrier:0
  23.           collisions:0 txqueuelen:1000
  24.           RX bytes:62234 (60.7 KiB)  TX bytes:146418 (142.9 KiB)
  25.           Interrupt:169 Memory:fb6e0000-fb700000
  26.  
  27. Command Result : 0 (Success)

Deploying wildcard SSL certificate for VMware Horizon 6

Friday, February 6th, 2015

Quick notes on how to deploy a wildcard SSL certificate with VMware Horizon 6 setup. In my case there is one Connection server and one Security server, both running Windows 2012 R2 Server OS. We also own a wildcard certificate covering our public domain, say domain.org.

(more…)

User based access control for Skype with Dante and FreeBSD 10

Saturday, October 4th, 2014

[20170903/ Yet another one. Since I rarely (read never) use Skype to call, I couldn’t spot it immediately, but all calls were actually dropped after 10 seconds. To fix it, you’ll need to open 3478/udp from your LAN to the outside world. More details are here. Confirmed to work with 7.39.32.102./20170903]

[20170512/ Another update. It actually came out that the latest Skype (confirmed with 7.36.0.101) does support socks, however there is an issue with the password length used to authenticate to the socks instance. Anything greater than 5 (five) characters fails. I don’t know whether it’s done deliberately, or there is some bug that’s never going to be fixed, but anyway, the workaround is either to use some generic account with the five-or-less-characters password, or disable socks authentication altogether./20170512]

[20170312/ Somewhere around first week of March 2017 (or end of February), Skype started dropping connections from versions 7.1.32.xx and below. When you try to log in, you’ll be presented with the message about outdated version. I’m not aware about any versions after 7.1.32 that support Socks. Despite of numerous bugs opened Socks functionality was never fixed, therefore the content of this article is no longer valid, and you won’t be able to use Skype with Socks. The configuration option is still there, but no connection attempts to the Socks server are made. Perhaps this is how they promote the usage of Skype Business Server./20170312]

Today we’re going to configure Dante running on FreeBSD 10.0-STABLE to allow Skype connectivity based on username/password stored in Active Directory. The version of Dante being used is 1.4.1 installed from ports and Active Directory is handled by Windows Server 2008 R2.

Note: as at the time of writing, the version of Dante available in FreeBSD ports collection is 1.4.0 and it’s marked as BROKEN because of the bug 192295. Use this patch to install 1.4.1.

Install required software:

  1. % cd /usr/ports/security/pam_ldap && make install clean
  2. % cd /usr/ports/net/dante && make install clean

Create /usr/local/etc/pam.d/sockd file:

  1. auth       required /usr/local/lib/pam_ldap.so
  2. account    required /usr/local/lib/pam_ldap.so
  3. password   required /usr/local/lib/pam_ldap.so

Create /usr/local/etc/ldap.conf file and fix permissions:

  1. host 10.9.128.1
  2. base OU=Users,DC=int,DC=domain,DC=org
  3. ldap_version 3
  4. binddn CN=socksd,OU=Users,DC=int,DC=domain,DC=org
  5. bindpw xxxxxxx
  6. pam_filter objectclass=user
  7. pam_login_attribute samaccountname
  1. % chmod 600 /usr/local/etc/ldap.conf

Adjust host, base, binddn and bindpw to reflect your environment.

Modify /usr/local/etc/sockd.conf file:

  1. logoutput: stdout /var/log/dante.log
  2. internal: 10.9.36.10 port = 1080
  3. external: 10.9.36.10
  4.  
  5. socksmethod: pam.username none
  6.  
  7. user.privileged: root
  8. user.unprivileged: nobody
  9. user.libwrap: nobody
  10.  
  11. client pass {
  12.         from: 10.9.128.0/24 port 1024-65535 to: 0.0.0.0/0
  13.         log: error connect disconnect
  14. }
  15.  
  16. socks pass {
  17.         from: 10.9.128.0/24 to: 0.0.0.0/0
  18.         command: connect udpassociate
  19.         socksmethod: pam.username
  20.         log: error connect disconnect iooperation
  21. }
  22.  
  23. socks pass {
  24.         from: 0.0.0.0/0 to: 10.9.128.0/24
  25.         command: udpreply
  26.         log: connect error
  27. }

Modify /etc/rc.conf to start Dante at boot:

  1. # enable dante
  2. sockd_enable="YES"

Configure Skype to use Socks with proxy authentication and check the logs of Dante:

  1. Oct  4 16:45:44 (1412433944.407661) sockd[482]: info: pass(1): tcp/accept [: 10.9.128.47.59574 10.9.36.10.1080
  2. Oct  4 16:45:44 (1412433944.525454) sockd[483]: info: pass(1): udp/udpassociate [: pam.username%usera@0.0.0.0.64526 10.9.36.10.60780
  3. Oct  4 16:45:49 (1412433949.196857) sockd[630]: info: pass(1): tcp/accept [: 10.9.128.47.59578 10.9.36.10.1080
  4. Oct  4 16:45:49 (1412433949.378804) sockd[499]: info: pass(1): tcp/connect [: pam.username%usera@10.9.128.47.59578 10.9.36.10.1080 -> 10.9.36.10.59578 64.4.23.143.33033
  5. Oct  4 16:45:49 (1412433949.380925) sockd[499]: info: pass(1): tcp/connect -: pam.username%usera@10.9.128.47.59578 10.9.36.10.1080 -> 10.9.36.10.59578 64.4.23.143.33033 (35)
  6. Oct  4 16:45:49 (1412433949.544730) sockd[499]: info: pass(1): tcp/connect -: 64.4.23.143.33033 10.9.36.10.59578 -> 10.9.36.10.1080 pam.username%usera@10.9.128.47.59578 (63)
  7. Oct  4 16:45:49 (1412433949.548340) sockd[499]: info: pass(1): tcp/connect -: pam.username%usera@10.9.128.47.59578 10.9.36.10.1080 -> 10.9.36.10.59578 64.4.23.143.33033 (40)
  8. Oct  4 16:45:49 (1412433949.706747) sockd[499]: info: pass(1): tcp/connect -: 64.4.23.143.33033 10.9.36.10.59578 -> 10.9.36.10.1080 pam.username%usera@10.9.128.47.59578 (3)
  9. Oct  4 16:45:49 (1412433949.962844) sockd[499]: info: pass(1): tcp/connect -: 64.4.23.143.33033 10.9.36.10.59578 -> 10.9.36.10.1080 pam.username%usera@10.9.128.47.59578 (144)

Since Dante is quite talkative make sure to rotate logs by editing /etc/newsyslog.conf file:

  1. /var/log/dante.log                      640  3     100  *     JB    /var/run/sockd.pid

NSD and OpenDNSSEC under FreeBSD 10 [Part 4: Firewall]

Sunday, August 31st, 2014

This is the forth part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

It’s just a reference for firewall freaks like me showing which ports need to be opened on each respective server.

I’m using PF on all four servers with the ‘deny all’ default rule.

NS-FEED needs to be able to send 53/udp to the signer and both slaves (to NOTIFY about zone changes). It has to accept incoming 53/tcp from the signer and both slaves (to allow zone transfers) and also it has to accept 53/udp from the signer (the signer will periodically poll the hidden master for zone changes):

  1. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.1 port = domain keep state
  2. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.2 port = domain keep state
  3. pass out quick on xl0 inet proto udp from xl0 to 10.9.128.2 port = domain keep state
  4.  
  5. pass in quick on xl0 inet proto tcp from 192.168.128.1 to xl0 port = domain flags S/SA keep state
  6. pass in quick on xl0 inet proto tcp from 192.168.128.2 to xl0 port = domain flags S/SA keep state
  7. pass in quick on xl0 inet proto tcp from 10.9.128.2 to xl0 port = domain flags S/SA keep state
  8.  
  9. pass in quick on xl0 inet proto udp from 10.9.128.2 to xl0 port = domain keep state

NS-SIGN has to be able to send 53/udp and 53/tcp to the hidden master (to request and perform zone transfer from the hidden master). It has to be able to send 53/udp to both slaves (to notify slaves about zone changes). It has to accept incoming 53/tcp from both slaves (to allow zone transfers) and also it has to accept 53/udp from the hidden master:

  1. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.1 port = domain flags S/SA modulate state
  2. pass out quick on xl0 inet proto udp from xl0 to 10.9.128.1 port = domain keep state
  3. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.1 port = domain keep state
  4. pass out quick on xl0 inet proto udp from xl0 to 192.168.128.2 port = domain keep state
  5.  
  6. pass in quick on xl0 inet proto tcp from 192.168.128.1 to xl0 port = domain flags S/SA keep state
  7. pass in quick on xl0 inet proto tcp from 192.168.128.2 to xl0 port = domain flags S/SA keep state
  8. pass in quick on xl0 inet proto tcp from 10.9.128.1 to xl0 port = domain flags S/SA keep state

NS-3 and NS-4 have to be able to send 53/tcp to the hidden master and the signer (to request zone transfers). They also have to accept incoming 53/udp and 53/tcp from anywhere to serve recursive DNS requests:

  1. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.1 port = domain flags S/SA modulate state
  2. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.2 port = domain flags S/SA modulate state
  3.  
  4. pass in quick on xl0 inet proto udp from any to 192.168.128.1 port = domain keep state
  5. pass in quick on xl0 inet proto tcp from any to 192.168.128.1 port = domain flags S/SA modulate state
  1. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.1 port = domain flags S/SA modulate state
  2. pass out quick on xl0 inet proto tcp from xl0 to 10.9.128.2 port = domain flags S/SA modulate state
  3.  
  4. pass in quick on xl0 inet proto udp from any to 192.168.128.2 port = domain keep state
  5. pass in quick on xl0 inet proto tcp from any to 192.168.128.2 port = domain flags S/SA modulate state

NSD and OpenDNSSEC under FreeBSD 10 [Part 3: OpenDNSSEC]

Sunday, August 31st, 2014

This is the third part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

In this exercise we’re going to configure our signing server NS-SIGN which will be running OpenDNSSEC with DNSSEC keys stored in SoftHSM.

For the sake of simplicity, let’s assume we’re going to host a zone called signed.org.

(more…)

NSD and OpenDNSSEC under FreeBSD 10 [Part 2: NSD]

Friday, August 29th, 2014

This is the second part in the series of articles explaining how to run NSD and OpenDNSSEC under FreeBSD 10.

Today, we’re going to deploy NS-FEED, NS-3 and NS-4 dealing with plain zones only. We’re not going to sign anything yet — we’ll deploy NS-FEED as a hidden master, configure it to feed NS-3 and NS-4 and configure NS-3/NS-4 to be masters for the ISP slave. This is probably the easiest part since configuration of NSD is quite easy.

(more…)

NSD and OpenDNSSEC under FreeBSD 10 [Part 1: Layout]

Wednesday, August 27th, 2014

In the following set of articles I’m planning to explain how to run NSD and OpenDNSSEC under FreeBSD 10. Since the setup involves a number of servers and at the end becomes “kind of” complicated I’m going to split it into series of articles, so it should be easier to track the progress.

Before we jump into technical nuances let me try to explain what exactly I’m trying to achieve and why.

Prior to deploying DNSSEC our setup was pretty straight-forward — a pair of authoritative DNS servers: one acting as a master and another one as a slave, with extra slave on the ISP side. Nothing fancy — it just works. With the introduction of DNSSEC a number of questions arose.

The first one is obviously related to the security: authoritative servers are exposed to the Internet. If the server is compromised your DNSSEC keys are gone, so we need to segregate authoritative servers from the signing engine and store keys in some secure media.

The second question is manageability: you will be dealing with regular renewals of ZSK keys and occasional renewals of KSK keys. Multiply this by a number of domains and you quickly realize that you would like to automate it to the maximum possible extent (either by using scripts like zkt or something more intelligent like OpenDNSSEC). And although KSK renewal is still manual ZSK renewal should be fully automated.

The third question is flexibility: you should be able to construct a “tree” of DNS servers in a such way that will allow you to add additional slaves quickly without touching the master node.

So here is the setup that we’ll be working on. I’m sure it’s not fully bullet-proof and there are plenty of things to improve, but it’s a good start.

2014082101

We’re going to configure four servers: NS-FEED, NS-SIGN, NS-3 and NS-4. ISP’s slave DNS is out of our control and is shown as a reference only, since it’s going to be one of the slaves. The operating system on all four servers is FreeBSD 10.0-STABLE (for those interested: KERNEL, make.conf, src.conf) with IPv6 disabled.

Here are more details about each server:

NS-FEED is our hidden master running NSD. It’s placed in the private LAN and it can only communicate with NS-SIGN, NS-3 and NS-4. This server will hold plain DNS zones. As you can see from the setup there are certain zones that don’t need to be signed — they will be fed directly to NS-3 and NS-4. Those zones that do need to be signed will be fed to NS-SIGN. This is the only server you need to access in order to make zone changes (add/delete/update records). The IP address of NS-FEED is 10.9.128.1.

NS-SIGN is our signing server running OpenDNSSEC. It’s also placed in the private LAN and it can only communicate with NS-FEED, NS-3 and NS-4. The primary role of this server is to get a plain zone from NS-FEED, sign it and transfer it to NS-3 and NS-4. This is the server where the DNSSEC keys are stored in a secure store provided by SoftHSM. All operational tasks, like how and when to (re-)sign zones, using what algorithm and such are handled by OpenDNSSEC. SoftHSM cryptographic store is accessible through a PKCS #11 interface which gives you a possibility to replace it with the “proper” hardware HSM in the future. Keep in mind that from the DNS perspective NS-SIGN is not an authoritative server — although it does zone transfers over AXFR/IXFR and listens on port 53/udp/tcp it doesn’t actually hold any zones so if you try to query it with dig you’ll get no response. The IP address of NS-SIGN is 10.9.128.2.

NS-3 and NS-4 are our publicly visible slaves running NSD. They are located in the DMZ, respond to 53/udp/tcp from the outside and keep plain and signed zones. However, they are not simple slaves (and this is where the fun begins), but also act as masters for other slaves (in our case it’s the ISP DNS). Without this hook, the slave from the ISP won’t be able to fetch zones, so you’ll have to feed it from NS-SIGN which you don’t want to do. IP addresses of NS-3 and NS-4 are 192.168.128.1 and 192.168.128.2.

Finally, ISP SLAVE DNS is the slave located on the ISP side. The IP address is 172.16.128.1.

So, to summarize: there is a hidden master (NS-FEED) holding plain zones and distributing it further, there is a hidden signer (NS-SIGN) getting plain zones from NS-FEED, signing and distributing them to NS-3/NS-4, there are two public slaves (NS-3 and NS-4) acting as slave+master, and there is a slave on the ISP side.

Tomorrow we’ll start with the first task: configuring NS-FEED and NS-3/NS-4 to deal with plain zones.

LDAP authentication with Squid

Wednesday, December 14th, 2011

A snippet from squid.conf allowing LDAP authentication from Mon-Fri business hours. Done on Ubuntu 10.04.2 (lucid) and Squid 2.7.STABLE7.

  1. # Configure LDAP auth helper
  2. auth_param basic program /usr/lib/squid/ldap_auth -v 3 -b "ou=Int,ou=People,dc=domain,dc=org" -u "uid" -h ldaps.domain.org
  3.  
  4. acl int-lan src 192.168.11.0/24
  5. acl daytime time M T W H F 08:30-12:30
  6. acl evening time M T W H F 13:30-17:30
  7.  
  8. http_access allow ldapauth int-lan daytime evening

LDAP authentication with Apache

Monday, January 10th, 2011

A snippet from httpd.conf allowing LDAP authentication. Done on Ubuntu.

  1. AuthType Basic
  2. AuthBasicProvider ldap
  3. AuthName "LDAP Secure Area"
  4. Require valid-user
  5. AuthLDAPBindDN "cn=username,ou=People,dc=domain,dc=org"
  6. AuthLDAPBindPassword XXXXXXXX
  7. AuthzLDAPAuthoritative off
  8. AuthLDAPCompareDNOnServer On
  9. AuthLDAPURL ldaps://ldaps.domain.org/ou=Internal,ou=People,dc=domain,dc=org?uid