The common way to bind to AD as an LDAP server is to use "Distinguished Name(DN)" and Password. The DN usually is in the form of: CN=username,CN=Users,DC=yourdomain,DC=com
To find out DN, you can use Sysinternal's Active Directory Explorer to connect to AD and browse to the user to find out.
According to this post on stackoverflow, http://serverfault.com/questions/497368/ldap-activedirectory-binddn-syntax, you can also use UPN, which typically has the value of:
<sAMAccountName>@<domain FQDN>
October 31, 2014
Linux Frame buffer screen capture
1. Calculate the screen size. For example 1920 x 1080. Make sure that the width is a multiple of 4. For example, for HD screen resolution of 1366x768, use 1368x768
2. dd if=/dev/fb1 bs=1368 count=3072 | gzip -c > screen.bgra.gz
Each pixel is 4 byte, B-G-R-A. So 1368x768 resolution takes 1368*768*4=1368*3072 bytes
3. transfer the file to a Linux computer with imagemagick installed (needs a version released after 2010), and then convert it:
gunzip screen.bgra.gz
convert -size 1368x768 -depth 8 screen.bgra screen.png
2. dd if=/dev/fb1 bs=1368 count=3072 | gzip -c > screen.bgra.gz
Each pixel is 4 byte, B-G-R-A. So 1368x768 resolution takes 1368*768*4=1368*3072 bytes
3. transfer the file to a Linux computer with imagemagick installed (needs a version released after 2010), and then convert it:
gunzip screen.bgra.gz
convert -size 1368x768 -depth 8 screen.bgra screen.png
Kerberos simplified
The 6 steps of Kerberos
Players:
User
Service (Can be any service that user wants to access, such as mail service)
Kerberos Authentication Service (AS)
Kerberos Ticket Granting Service (TGS)
+--------------------+----------------------+
| | |
| Kerberos AS | Kerberos TGS |
| | |
+---------+----------+--------+-------------+
^ | ^ |
| | | |
1 | |2 3 | | 4
| | | |
| | | |
+-------------------+ | | | | +-----------------------+
| |--------------+ | | | | |
| |<--------------------+ | | | |
| +------------------------------------+ | | |
| User |<----------------------------------------+ 5 | Mail Service |
| +---------------------------------------------------------------->| |
| |<----------------------------------------------------------------+ |
+-------------------+ 6 +-----------------------+
Step 1: User ---- Username, Timestamp ----> Kerberos AS
Step 2: Kerberos AS ---- TGT=[K(user,tgs)<-P(tgs)], K(user,tgs)<-P(user) ----> User
Step 3: User ---- TGT<-P(tgs), user_name, service_name, authenticator<-K(user,tgs) ----> Kerberos TGS
Step 4: Kerberos TGS ---- ST=[K(user,service)<-P(service)], K(user,service)<-K(user,tgs) ----> User
Step 5: User ---- ST<-P(service), user_name, authenticator<-K(user,service) ----> Service
Step 6: Service ---- OK, authenticator<-K(user,service) ----> User
Authenticator = (sender_name, sender_address, timestamp, lifespan) <- SessionKey
K(user,tgs) : a session key, randomly generaged by Kerberos, shared betwee user and TGS
P(tgs) : a key based on the password of the tgs service. It's a password known only by the tgs service
P(user) : a key based on the password of the user
K(user,tgs)<-P(user) : meaning that K(user,tgs) is encrypted with the key of P(user)
TGT : Ticket Granting Ticket. It's just a token that needed for the user to talk to TGS. It contains
a session key known only by user and TGS.
Keytab files
In kerberos step 1, users can enter password to obtain the TGT from Kerberos TGS, what about services/devices? Kerberos allow the value P(user) to be exported and saved to a file, usually named keytab. This allows the service to authenticate users without talking to Kerberos server.
Players:
User
Service (Can be any service that user wants to access, such as mail service)
Kerberos Authentication Service (AS)
Kerberos Ticket Granting Service (TGS)
+--------------------+----------------------+
| | |
| Kerberos AS | Kerberos TGS |
| | |
+---------+----------+--------+-------------+
^ | ^ |
| | | |
1 | |2 3 | | 4
| | | |
| | | |
+-------------------+ | | | | +-----------------------+
| |--------------+ | | | | |
| |<--------------------+ | | | |
| +------------------------------------+ | | |
| User |<----------------------------------------+ 5 | Mail Service |
| +---------------------------------------------------------------->| |
| |<----------------------------------------------------------------+ |
+-------------------+ 6 +-----------------------+
Step 1: User ---- Username, Timestamp ----> Kerberos AS
Step 2: Kerberos AS ---- TGT=[K(user,tgs)<-P(tgs)], K(user,tgs)<-P(user) ----> User
Step 3: User ---- TGT<-P(tgs), user_name, service_name, authenticator<-K(user,tgs) ----> Kerberos TGS
Step 4: Kerberos TGS ---- ST=[K(user,service)<-P(service)], K(user,service)<-K(user,tgs) ----> User
Step 5: User ---- ST<-P(service), user_name, authenticator<-K(user,service) ----> Service
Step 6: Service ---- OK, authenticator<-K(user,service) ----> User
Authenticator = (sender_name, sender_address, timestamp, lifespan) <- SessionKey
K(user,tgs) : a session key, randomly generaged by Kerberos, shared betwee user and TGS
P(tgs) : a key based on the password of the tgs service. It's a password known only by the tgs service
P(user) : a key based on the password of the user
K(user,tgs)<-P(user) : meaning that K(user,tgs) is encrypted with the key of P(user)
TGT : Ticket Granting Ticket. It's just a token that needed for the user to talk to TGS. It contains
a session key known only by user and TGS.
Keytab files
In kerberos step 1, users can enter password to obtain the TGT from Kerberos TGS, what about services/devices? Kerberos allow the value P(user) to be exported and saved to a file, usually named keytab. This allows the service to authenticate users without talking to Kerberos server.
A really helpful story telling about Kerberos the authentication mechanism
http://web.mit.edu/kerberos/dialogue.html
I have read quite a few articles about Kerberos. Among them the above dialog is the most helpful. It does not hurt that it came from the original authors who help designed Kerberos.
I have read quite a few articles about Kerberos. Among them the above dialog is the most helpful. It does not hurt that it came from the original authors who help designed Kerberos.
October 17, 2014
Windows Server LDAP MaxPwdAge, MinPwdAge
When using AD Explorer software to query Windows Server, on a particular domain, you can see the maximum and minimum days required for password to change. These values show up as HEX values such as:
Max: 0xFFFFDEFF0AA68000
Min: 0xFFFFFF36D5964000
This is how to convert them to actual days:
( 0xFFFFFF36D5964000 - <64-bit value> ) / 0xC92A69C000 + 1 = answer ( in days)
Basically, the time unit here is 100ns (See http://en.wikipedia.org/wiki/System_time to see how Windows use 100ns as their system time unit). So
1 day is 24*3600*10,000,000 = 864000000000 = 0xC92A69C000
Starting from an unsigned 64-bit 0 value,
1 day = 0 - 0xC92A69C000 = 0xFFFFFF36D5964000
2 day2 = 0xFFFFFF36D5964000 - 0xC92A69C000 = 0xFFFFFE6DAB2C8000
3 days = 0xFFFFFDA480C2C000
...
41 days = 0xFFFFDFC835104000
42 days = 0xFFFFDEFF0AA68000
43 days = 0xFFFFDE35E03CC000
44 days = 0xFFFFDD6CB5D30000
...
89 days = 0xFFFFBA10413C4000
90 days = 0xFFFFB94716D28000
So for the above example:
Max: 42 days
Min: 1 day
Max: 0xFFFFDEFF0AA68000
Min: 0xFFFFFF36D5964000
This is how to convert them to actual days:
( 0xFFFFFF36D5964000 - <64-bit value> ) / 0xC92A69C000 + 1 = answer ( in days)
Basically, the time unit here is 100ns (See http://en.wikipedia.org/wiki/System_time to see how Windows use 100ns as their system time unit). So
1 day is 24*3600*10,000,000 = 864000000000 = 0xC92A69C000
Starting from an unsigned 64-bit 0 value,
1 day = 0 - 0xC92A69C000 = 0xFFFFFF36D5964000
2 day2 = 0xFFFFFF36D5964000 - 0xC92A69C000 = 0xFFFFFE6DAB2C8000
3 days = 0xFFFFFDA480C2C000
...
41 days = 0xFFFFDFC835104000
42 days = 0xFFFFDEFF0AA68000
43 days = 0xFFFFDE35E03CC000
44 days = 0xFFFFDD6CB5D30000
...
89 days = 0xFFFFBA10413C4000
90 days = 0xFFFFB94716D28000
So for the above example:
Max: 42 days
Min: 1 day
October 16, 2014
If you have a computer that joins to a domain, you can use LDAP to bind to the domain name controller and find a lot of information. Here is how you do it:
1. open a "cmd" window, and do: echo %logonserver% . This tells you the domain controller's name
2. download sysinternals AD explorer software, and connect to the domain controller
3. On the left tree, suppose your company's domain is abc.com, click on "DC=abc,DC=com"
4. In the subtree, click on "OU=...", and keep click on "OU=..." in the subtrees, until your find all the users with "CN=...". There you can see all the users of the domain, and all other information.
1. open a "cmd" window, and do: echo %logonserver% . This tells you the domain controller's name
2. download sysinternals AD explorer software, and connect to the domain controller
3. On the left tree, suppose your company's domain is abc.com, click on "DC=abc,DC=com"
4. In the subtree, click on "OU=...", and keep click on "OU=..." in the subtrees, until your find all the users with "CN=...". There you can see all the users of the domain, and all other information.
Subscribe to:
Posts (Atom)